ground-db
ground-db copied to clipboard
Feature request: persistence
It would be nice to keep the Grounded collection available for the next restart; if the user starts the app without an internet connection the old data will be used.
The latest cached data should be available on startup - if not it would be an issue - it's a bit unclear if this isn't happening. Let me know @KoenLav
I should mention I'm troubleshooting a Chrome App, but it has access to IndexedDB and localForage works fine, so it shouldn't be an issue.
I'm subscribing to collections in Meteor.startup: Meteor.subscribe('tables') Meteor.subscribe('tableplans')
Afterwards (still in Meteor.startup) I ground them: Ground.Collection(Tables) Ground.Collection(Tableplans)
When I restart the app the Tables and Tableplans collections are initialized, but they remain empty (the data which was available before is not used).
I already checked to see whether this has something to do with localForage in a Chrome App, but localForage works fine (I can store values using localForage and get them after restarting the app).
Any insights would be appreciated!
Also, probably unrelated, I keep getting the warning: "Cannot call a class as a function" which is raised by babelHelpers.classCallCheck(this, GroundCollection);, but it only happens on the first Ground.Collection call (not subsequent calls).
Other than that the 1.0 alpha seems to work just fine!
@KoenLav ok - thanks - the babel error is odd - what version of Meteor are you using?
1.2.1
I am too having trouble with data not being persisted. I have the following code, and it always logs 0 when I visit the page, although it contained data when I previously left the page.
var Data = new Ground.Collection('settings', {connection: null})
console.log(Data.find().count())
It worked as expected a year ago. Since we're now two noticing this problem, I guess there's a bug somewhere.
I've released 2.0.0-alpha.1
Notes about the new version, migration and what it doesn't do - The issue might be resolved in that version, let me know what you think
I have about 10 collections grounded and all of them except 1 work fine offline after an app restart. The offending table is the largest - over 5MB of HTML text records. The next biggest is just under 1MB. Is there a maximum size that I should be trying to stay under? Would it be advisable to compress the HTML text before putting it in the collection?
Ground db II does not compress your data - you could use different kinds of compression, the better you know your data the better you can compress it. The minimax package helps you compress js objects and allows you to create a dictionary for better compression. mobile browsers are usually limites to around 4.5mb most desktop browsers have no limit or will ask the user for permission.
I also seem to have a problem with a lack of persistence.
I have the following code.
Meteor.startup(function () {
Cells = new Ground.Collection('cells', { connection: null });
console.log("Number of cells: " + Cells.find().count());
if (Cells.find().count() == 0) {
for (i = 0; i < Session.get('cellsLat'); i++) {
for (j = 0; j < Session.get('cellsLng'); j++) {
Cells.insert({ i: i, j: j, visible: true });
}
}
}
});
After every restart and reload (pressing the reload button in the browser), Cells.find().count() equals 0.
Am I missing something obvious, here?
I am using ground db in my meteor & ionic app. I am also facing a problem in data persistence between app restarts. Initially when the app starts and then goes into offline mode during navigating the app, the data is retained. However if I close and restart the app in offline mode, the data is lost. My ground db version is 2.0.0-rc.7 and ionic version is 3.1.1
I have found that the data is not always available at Meteor.startup
- but you can dig into the storage tier, and subscribe to a ready
promise:
OfflineCollection.storage.ready()
.then(function () {
// now it's ready
})
or
// inside an async function
await OfflineCollection.storage.ready()
// now it's ready
I know this is an old issue, but I wonder whether this jives with what others have found.
This is one slow moving issue :)
@CaptainN : your suggestion does not appear to work for me. My offline collection is reported to be ready, but still without the data that should have been in there. After a short while, the data that was supposed to be in my offline collection then appears.
For me, this is particularly an issue with a 'Settings' collection, which contains settings for the current user and which are defined on the user's first visit, or retrieved on subsequent visits. I now solve this by regularly checking the user's settings and removing any newer duplicates. Not ideal, but it works.