Is there anyway to open and read a SQLite database file on GAE?
I am currently uploading dbs to blobstore as admin and serving them publicly to user clients. I just can't read them in the GAE admin interface.
You can use SQLITE on Google App Engine. The problem has nothing to do with the support of certain libraries. It has to do with read-only file system. There is, however, a writable /tmp directory. If your app on startup first copies the db.sqlite3 file to /tmp/db.sqlite3 and references this path as database path, it will work.
There are, however, drawbacks.
1. This is not a "real" directory i.e. it's stored im memory. If database is too large, one will get problems.
2. Each instance has its own copy of db.sqlite3 file. Does not scale well.
Here is a django example:
Using SQLITE for local Django development for Google App Engine?
Short answer, no it is not possible to use a SQLite database on a standard Google App Engine application as it is not currently supported. However, you can give a try at implementing your own configuration with the App Engine Flexible Environment that allows to take advantage of custom libraries through Infrastructure Customization.
In case you would want to experiment, here is a sample Django application designed to be run with its default SQLite database on the App Engine Flexible Environment. Still, make sure to read the database notice providing alternative data storage options and explaining that SQLite data does not persist upon instance restart.
Related
I have lately re-discovered embedded databases such as Sqlite (sql, relational) and LiteDb (noSql) and I like working with them for small web apps or mobile apps.
However, I cannot find any good answer to where to place them. Where to put them if:
The web app is likely to be containerized
The database can grow dynamically
Changes to the code and new deployments should not risk losing any change in database
1. Database file as part of solution (versioned in source control)
I've seen places where the *.db file is placed somewhere in the solution and it's versioned in source control.
I can see how this could be a problem as the database can be modified outside the context of development (i.e: when the app is up and running in production, the DB may change and in the next deployment the db may be overwritten if no backup/restore process in place)
Sometimes I have seen it inside wwwroot/App_Data. See this for instance. I assume App_Data is some kind of protected folder and its files cannot be server statically by the web server (is it?). Otherwise this is even worse.
2. Database file in binary folder
When testing, it's fine to have the database file generated somewhere in the bin folder, but this causes a similar problem as the previous one. What happens when a new software version is released and therefore the database file is overwritten in production?
So the questions are:
Is there any good practice regarding where to place embedded database files?
Is there any alternative to having backup/restore processes to avoid the described data-loss scenarios?
What happens when the app is contenierized and the database file grows once deployed? If the file is inside a container along with the running application, can it grow indefinitely? I don't recall specifying anything about a maximum size for containers anywhere when creating images..
Is having the DB in an external storage such a cloud blob store the alternative? I'm guessing the real benefit of embedded databases is gone if the file is in a different host.
Any good read about this would be appreciated.
PS:
I am asking for AspNet Core apps mainly because I see some projects using the wwwroot folder to place the embedded DB, but the question applies to any technology/framework.
This other question doesn't help either.
We have an application written in Mono that needs to communicate with an Finder Sync App extension.
All is working fine until we tried our app on El Capitan instead of on Yosemite.
We use a shared SQLite database to tell what paths are in which state and use NSDistributedNotificationCenter for communication between the two.
The shared SQLite database is outside of the sandboxed env so we have putted an excepention in our entitlements com.apple.security.temporary-exception.files.home-relative-path.read-write
If we remove this exception from the app extension, the extension works (but obviously we can't read our db)
Then we tought of putting the SQLite DB into memory, but shared memory databases isn't possible over multiple processes.
I can't find how I can create a NSFileHandle for a Sqlite Connection.
We could send over all the info to the application extension, but then that has to keep it in memory (preferably in a SQLite, cause we need to do some querying.)
Does anyone has some pointers of what we could do?
Try to look in The Application Group Container Directory it might do in your case. Basically it allows you to have shared folder between apps/extension.
App group container directories. A sandboxed app can specify an entitlement that gives it access to one or more app group container directories, each of which is shared among all apps with that entitlement.
After some research on similar problem I found it's much easier to have simple TCP server in main app that responds to extension with file status. This way you can easily broadcast file status change to all extension instances etc.
I have been using a central MS SQL database located in the cloud to develop a web site project. I have recently found myself in situations, when I need to develop without the internet connection. I want to begin to use a locally available copy of the existing database, put it in App_Data folder.
What is the correct set of steps I need to undertake to get the project to work with local DB?
For example:
Detach a db from an existing SQL instance.
Copy to a development machine.
etc.
Moving a SQL-Server DB is not that hard. Look here for some methods to do it.
http://support.microsoft.com/kb/314546
I usually find the sp_detach + sp_attach method really easy.
I would create an empty shell database locally, then use one of the many schema comparison solutions available to make the local database look exactly like the cloud database.
Correct way is to create and regularly update your standalone copy of database using import/export. In particular MS SQL Server provides Import/Export Wizard tool for such purpose.
Make a backup
Copy backup file
Restore on your server
Restore/organise users
I want to provide iCloud support for my wrapper around sqlite. Is not using coredata.
I wonder how enable iCloud for it. The database content is changed all the time (is for invoicing). Also, if is possible to have some kind of versioning will be great.
Exist any sample I can use to do this?
The short answer is no, you would need to use Core Data as you suspected. Apple has stated that sqlite is unsupported.
Edit: Check out the section on iCloud that's now in the iOS Application Programming Guide under Using iCloud in Conjunction with Databases
Using iCloud with a SQLite database is possible only if your app uses
Core Data to manage that database. Accessing live database files in
iCloud using the SQLite interfaces is not supported and will likely
corrupt your database. However, you can create a Core Data store based
on SQLite as long as you follow a few extra steps when setting up your
Core Data structures. You can also continue to use other types of Core
Data stores—that is, stores not based on SQLite—without any special
modifications.
You can't just put the SQLite database in the iCloud container, because it might get corrupted. (As you modify an SQLite DB, temporary files are created and renamed, so if the sync process starts copying those files, you'll get a corrupt database.)
If you don't want to move to Core Data, you can do what Core Data does: store your database in your document folder, and store a transaction log in the iCould container. Every time you change the database, you add those changes to a log file, so you can play them back and make equivalent changes on other devices.
This gets pretty complicated: aside from getting the log/reply logic right, you'll want to coalesce redundant changes and periodically collapse the log into a complete copy of the database.
You might have an easier time developing a solution if you can exploit knowledge of your application (Core Data has to solve the problem in the general case). For example, you could save invoices as separate files in the cloud container (text, Property List, XML, JSON, whatever), writing them out as the database changes and only importing ones if the system tells you they were created or changed.
In summary, your choice is either to migrate to Core Data or write a sync solution yourself. Which one is best depends on the particulars of your application.
I can create a sqlite DB in phonegap/html5 via window.openDatabase. I am going to have a large amount of data, so I want to ship it with the app.
So can I store a sqlite DB somewhere, within the app (It needs to work on both iOS and Android). I particular where is the shortName.db stored when I call
var db = openDatabase(shortName, version, displayName, maxSize);
And can I pre-populate this sqlite file. (In the phonegap environment)
Listed here are some solutions for iphone and android:
http://groups.google.com/group/phonegap/browse_thread/thread/5e57a728dc66a2a1?pli=1
I've not used PhoneGap, only created HTML5 apps that use Web SQL. However, if you're asking whether you can ship an app with a pre-populated SQLite database, then yes you can. Probably the simplest approach would be to provide the table creation scripts as part of the app. When it's first fired up, you can have the scripts run, and your database will then be fully initialised.
An alternative approach for deploying bulk data I came up is simply serialize it into text files and deploy the files together with the app.
You can use the File API provided by PhoneGap to load these files as strings, and parse them with Ext.util.JSON.decode().
Finally, use the MemoryProxy to integrate the decoded data with the rest of Sencha Touch and you are golden.