[question]usage with meteor 1.3

[dagatsoin]

Hi, I just found your package while looking around to have a CouchDB like behavior with sync offline/online and persistant data. I will use Cordova and Meteor 1.3 for my project.

Do you know any issues to use the alpha version of GroundDB with 1.3?

[ecerroni]

I was wondering about the same. Looking forward to get an answer here.

[dagatsoin]

Looking to the alpha 1.0 branch, there is no update since August '15? Is this project frozen?

[dagatsoin]

I simply tried:

var list = new Meteor.Collection(null);
var groundList = new Ground.Collection(list, 'list');

I got: Ground.Collection requires a collection name [missing-name]

So I think it is not compatible yet.

[ecerroni]

Try var list = new Mongo.Collection(null);

[dagatsoin]

Yep, it is what I did, I pasted the wrong part.

Plus, the package removes standard-minimifiers.js and as the last commit on the alpha branch was in November I don't think the library is up to date.

So for now, it is not usable in 1.3.

[ecerroni]

Too bad. It's a package I used for a mobile app with great success.

It's perfect for offline mobile apps. I hope the library will eventually be updated for Meteor 1.3

[dagatsoin]

I hope so much too! And I will attempt a nasty ping to @raix to know his plans about this :)

[raix]

Hi guys - working on it :)

[dagatsoin]

<3

[ecerroni]

Great! :)

[veeramarni]

Is the issue fixed for Meteor 1.3 version?

[dagatsoin]

Hi @raix do you need some help for the next grounddb version? I don't know if I have the level for collaborating on this but if you have got clear task todo I can look at it.

[raix]

@dagatsoin thanks sorry about the delay - solving this issue just got in my sprint - I'll try to outline things in issues/milestones so others can contribute and help out.

[dagatsoin]

Ok, count me in.

[raix]

Hey guys,

cc.: @dagatsoin

Take a look at 2.0.0-alpha.2 branch https://github.com/GroundMeteor/db/tree/grounddb-caching-2016 - review / feedback is welcome

I've decoupled the new ground db to be a pure caching db (at least for now) - The major reason is that it's more important to have better control of the cached data. Second reason is than you might want to swap out the source at some point.

Migration

Migration would probably look something like:

  // current "connection-driver"
  var foo = Ground.Collection('bar', {
    cleanupLocalData: false, // Manually trigger cleanup
  });

  Meteor.subscribe('bar', () => {
    foo.removeLocalOnly(); // Match grounded data with subscription
  });

  // current "ground db II"
  const bar = new Mongo.Collection('bar');
  const foo = new Ground.Collection('foo');
  foo.observeSource(bar.find()); // Cache bar or a subset of bar

  Meteor.subscribe('bar', () => {
    foo.keep(bar.find()); // Match grounded data with subscription or a subset
  });

  // You might also want to point bar finds to foo - this is a custom case depending
  // on implementation
  bar.find = function(...args) {
    return foo.find(...args);
  };
  bar.findOne = function(...args) {
    return foo.findOne(...args);
  };

Again the GroundDB II does not cache/resume outstanding method calls or try to be clever about things - but it supports localforage (localstorage/indexeddb/websql and SQLite on cordova) so it's non blocking.

Comparison with approximate 2.000 documents:

Current ground db: (Notice the white screen at first while ground db is blocking)

Ground db v2:

[dagatsoin]

Love it! I need to finish a project first this week and I will jump into it. This new version seems very decoupled, smart move! I already use SQLi through Mapbox offline, so I may be able to reuse it with ground db instead of having two different persistant DBs. Can't wait to install it!

[KoenLav]

"Again the GroundDB II does not cache/resume outstanding method calls or try to be clever about things"

Does this mean it will no longer forward collection changes made when the application is offline?

[raix]

@KoenLav it's a behaviour that can be added later on or by a package, for now I want to keep ground:db II simple and decoulped from the source - eg. you could populate the data from other sources.

Resuming out standing method calls are not without issues - one is the missing callback, we cant resume callback instances which makes the code feel odd.

There might be use cases for it - but I'd rather tackle it from a different approach: if the server wants to update the local data you might want to check if the client data is newer than the server (eg. a committed change not received correctly by the server) - in this case theres a conflict, so having the option to opt in a conflict handler will allow the client to catch that send a new commit to the server or even ask the user if it cannot be resolve automatically.

I also want to allow the concept of "WIP" eg. allowing the user to work on stuff without committing it to the server.

All in all why I'm cutting down complexity - we want to be able to reason about things :)

[KoenLav]

I understand.

I did however run some tests and it does seem that changes made to collections while the client is offline are later reflected on other clients after the first client regains connectivity.

Do note: I did not modify any of our code, I simply make use of the notation: Meteor.subscribe('products') Ground.Collection(Products) and it works.

Is this intended behavior with the 2.0 alpha branch then?

[raix]

@KoenLav yeah,

V1 listens to the localstorage events making updates in one tab also update in other tabs even if the app is offline, it's a feature that might be implemented in V2 later - since it can be useful eg for pure offline collections etc. (more or less a refactor of this chuck)

The outstanding method resume is part of Meteor - but will not be persisted in V2 (basically this chuck that resumed methods)

[KoenLav]

I see, I was just a little worried that simple changes to a collection would not be 'resumed' after reconnecting with the server (e.g. it could leave clients out of sync at some point). But this does not seem to be the case, as I pointed out above.

Initially not supporting resuming outstanding methods seems like a smart thing to do.

[mrlowe]

Hi @raix, I'm just showing up to the Meteor+GroundDB party and seeing this note about your next version, specifically the bit about no longer resuming outstanding methods. It's a little confusing to me, though. Suppose I want to insert an object into a collection. Can that be done securely without using a server method?

[dagatsoin]

@raix I am ready to dive in groundb. Question: how to manage storage system? I use Cordova and will surely use the SQLite plugin. So how to make sure that grounddb will use SQLite?

[dagatsoin]

And which SQLite plugin must we use? https://github.com/litehelpers/Cordova-sqlite-storage or https://github.com/nolanlawson/cordova-plugin-sqlite-2?

[atulmy]

@raix I'm building an app for a clinic and would require data offline. Its on Meteor 1.3. Which version should I go ahead with? Ground DB 1 or if 2 alpha is usable on production as well? Any help or alternatives would be useful!

[raix]

@dagatsoin the 2.0.0-rc.3 uses localforage - so you can install the SQLite localforage plugin and configure a localforage storage manually:

import localforage from 'localforage';
import Ground from 'meteor/ground:db';

const fooStorageAdapter = localforage.createInstance({
  driver: window.cordovaSQLiteDriver._driver, // Not tested - depends on the plugin
  name: 'foo',
  version: 1.0,
});
const foo = new Ground.Collection('foo', {
  storageAdapter: fooStorageAdapter,
});

foo.observeSource(bar.find());

@atulmy on Meteor 1.3 I would use 2.0.0-rc.3 - the old version might break

[dagatsoin]

hi @raix I don't get how to install the 2.0.0-rc.3. Currently I have downloaded the last commit in /packages/grounddb then I did meteor add ground:[email protected]

The terminal displayed:

Changes to your project's package version selections:

dispatch:kernel                   added, version 0.0.6
dispatch:request-animation-frame  added, version 0.0.1
ground:db                         added, version 2.0.0-rc.3
ground:servertime                 added, version 2.0.0
raix:eventemitter                 added, version 0.1.3
raix:eventstate                   added, version 0.0.4

So I guess it is OK. But When I try to import it with import Ground from 'meteor/ground:db'; Webstorm does not find the path.

[dagatsoin]

and import localforage from 'localforage'; is also marked in red. import localforage from 'localforage-cordovasqlitedriver/src';is not marked in red but seams weird to me.

Could be useful to know the installation steps.

Thx :)

EDIT: note I am using Typescript. I will look on the type definition file side.

[raix]

oh - there might be issues with the typescript/meteor import syntax - not sure if it's actually working.

the latest ground db is not using SQLite - it should add the npm version of localstorage however. ref

[dagatsoin]

You mean it does not use SQLite "directly"? But it is faisable if I use localforage-cordovasqlitedriver?