I've got a meteor application where I initialize a bunch of data on startup. The data is provided by mongodb collections and gets written into several caches. Now, some of the data has to be updated from other sources before it's supposed to be used. But by the time the data gets updated, it's already been distributed to the caches. I'd need a way to properly bootstrap the application (initialize and update data sources) before they can be used.
Something like:
Startup application
Update data sources (collections)
Mark collections as ready to be used
I suppose another approach would be to reactively update the all the caches when the data changes, but that's actually not that easy.
Related
I'm working with Azure's offline-sync API.
(It's REALLY GREAT so far, but since it's still new-ish it doesn't have comprehensive documentation, only tutorials. We need to craft dependable integration tests, and we're finding that tricky because we need to rely on published behavior in official docs for that... or dig into the source, but that is liable to change at any time.)
The samples do this:
var store = new MobileServiceSQLiteStore("localstore.db");
The comments mention "initializes local store".
I assume the local sync database is a "throw-away" asset, as it can be recreated at will.
Is the expected behavior that it will create the local SQLite file if it does not exist, or it will recreate the file each time the mobile app starts and that call is made?
The tutorials are augmented by the HOWTO documentation (available under Mobile > Develop - in the same area as the tutorials) and the GitHub Wiki and the github.io pages for the SDK.
The local store is created if it doesn't exist, and new fields are added to tables if they are needed. It's sometimes good to delete the database - for example, if you reduce the field count in your mobile app (the process only adds fields). If you do this, the database will be re-created when the app is next restarted.
I'm getting stock quotes which happen a few times a second. I'm using meteor to display those quotes. I don't think meteor can keep up with the database. What's the best way to keep meteor speedy?
Should I set my query to be non-reactive then somehow manually call when meteor should re-render the templates?
If you are updating your db directly (outside of meteor), than meteor will take 10 seconds to reload and recompute the data changes from the database.
If you are updating your db through a DDP connection, than those changes should reflect to your meteor UI almost instantaneously, certainly keeping up with a few updates per second.
Apart from this, your publish function should not expose all fields of a document in bulk. Instead, you should publish just what is necessary to populate your UI.
I went thru the docs but couldn't find how can I perform specific operations when app is being installed or when app is being updated.
What I want to do is, create table when app is being installed and if in future, db schema changes, I want to perform those operations when app is being updated.
According to me .. the best place to do these changes are in the code. so whenever the application starts up first time after getting updated.. you do all the db schema changes.
This makes sure that your application is fully updated before you touch any database and secondly u do not have to write any special logic separately while installing / updating the application.
I have an AIR application and I would like use SQLite instead of an XML file to populate the database. I've seen people create the database on the fly and import the data when the application first launches. But also people are using existing databases. What approach do you use to prepopulate the database? Is there a tool to enter basic initial data (~200 records and 2 tables) or should I create the database and contents manually when the app is first installed.
More context
This is a mobile AIR application using Flex 4.6.
There are numerous tools to manage SQLite databases, such as Lita which is an open source AIR application.
If there is no need to revert the database back to its original content, then it could simply be packaged in the app with your populated content.
If restoring the database to its original populated data is required, you could keep a copy of the original database and stage it to the active database in use, thereby replacing the database.
Depending on data and parity of your app to the database model, it wouldn't be unreasonable to populate your database via programmatic implementation in code executed at first launch. There is overhead both in initial launch of your app and perhaps mostly in code you must generate and maintain to create the database.
Typically, I would only follow this pattern if I have a default model with serialization of that model. As in, if I had already built a commit of preferences style data from my models to persist in a database.
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.