How does Meteor.js detect changes in MongoDB or Mysql? Does it add triggers, or does it poll for changes? If if polls for changes then this seems a rather expensive operation
Update
I also found an explanation on the Meteor site after some more digging around:
https://www.meteor.com/livequery
For MongoDB, Meteor tails the operation log (oplog) for changes. In production, this requires the database to be set up as a replica set (a one-member replica set is fine); if it isn't then it will fall back to polling. In development mode, oplog tailing is enabled by default. For more information, see this (slightly out-of-date) wiki page.
There's no native MySQL support in Meteor. There are packages which add MySQL support, but you'll have to read those packages' documentation to see if it uses triggers or polling.
Related
I want to control background sync of google-firebase's firestore db with persistance mode (PersistenceEnabled to true).
I'm afraid the old version client, works offline and don't know the app's version-up (with some destructive updates), may upload local-data to server when change to online.
In this case, I want to check current app versions and allow/not allow before sync.
Is there any solution?
Data in the cache is only updated when you attach a listener/observer to it. There is no automatic synchronization happening for the data in the offline cache.
This means that you can add a version check to your application startup code, before you attach any observers. Simply store a database-version field in a global document, and check against that upon application startup. If the version is greater than what the app was made to handle, show an upgrade prompt.
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 have a website solution that uses on SQLite database for each tenant account. Without going into much depth about why we chose this solution, we chose it due to SQLite support on distributed/offline systems.
All databases are manipulated using the same PHP file structure. I wish to update the database version iteratively for all accounts so that they are all at the same version number.
I have a script that loops over each, and can use either PHP(Yii) or the shell to execute queries.
I would like to wrap the manipulation to each database in a transaction. It appears as though DDL commands may already be auto-commit in nature.
Question: How to accomplish a SQLite DB upgrade which, if it fails, will report a failure? Using that report, I could prompt the system to re-attempt or report an error to an admin. Ideally, I would like to wrap the whole upgrade in a transaction to prevent inconsistencies, but I'm fairly certain that this is not possible.
One thought I had was to backup the database temporarily during upgrade, and delete it on success.
As CL stated in the comments, DDL is fully transactional in SQLite. So, for each database in our system, we wrap it in a transaction, and it executes atomically. We leverage the application to ensure that all databases upgrade successfully if any fail during upgrade.
I am trying a test to move all my development to Nitrous.io IDE, but with limited space in my Nitrous box I want to permanently host my Mongo databases at MongoHQ.com. Currently each day I need to set my MONGO_URL by running:
export MONGO_URL='mongodb://<user>:<pass>#paulo.mongohq.com:12345/<db>'
If I fire up another console or logout of Nitrous my MONGO_URL needs to set again.
How can I set the development MONGO_URL for good per meteor app? I cannot find a config file anywhere.
Nitrous support helped me find a quick solution. Just wanted to answer it here for others with the same issue.
Open ~/.bash_profile and enter your DB information.
example:
export MONGO_URL='mongodb://jimmy:criket#paulo.mongohq.com:12345/mynitrobox'
Next in the console run source ~/.bash_profile to load the settings.
This sets the DB for your entire node.js box, not individual meteor apps, so you may want to structure your Mongo collections accordingly with subcollections.
you can do this in one line like so:
MONGO_URL='mongodb://<user>:<pass>#paulo.mongohq.com:12345/<db>' meteor
I don't know much about Nitrous.io but in AWS EC2 I have an upstart job that runs this for me when the server starts.
I gist'd my approach a while back, I've since changed it a bit but this still works:
https://gist.github.com/davidworkman9/6466734
I don't know that this will help you in Nitrous.io though, good luck!
Can meteor application be launched offline, when no server connection is active,
for example from html5 application cache in browser.
Or being saved to offline folder.
of course no data propagation to server, but maybe some local cache.
EDIT: how about saving events to local storage when offine?
Yeah, theoretically, this should be doable by creating a HTML5 cache manifest. I asked about this here:
How can I add a cache manifest to a Meteor app?
I had the same query. This is worth looking at for persisting your data offline:-
https://github.com/awwx/meteor-offline-data
Meteor has an appcache package (check the docs) and it currently being used in the docs itself.