Allow custom migrators, so that structured store backends like parse can be used

[drewmccormack]

There are many BaaSes. They have basic entity models. They could be leveraged by mirroring the ensembles internal model. This could be done at the migrator level.

[drewmccormack]

Would not be much advantage to this. Better would be to have a means to populate a DB or cloud engine from the transaction logs. Then you could build a true web app on top of the result. So we really need a node.js or similar app that can run in the cloud, read cdeevent files, and populate MySQL, Parse, SQLite etc.

[Alydyn]

So, I'm confused, is a Parse.com backend support? 😄

[drewmccormack]

There is no Parse backend at the moment, though you could add one in a few hours by simply storing files in Parse.

This issue is about allowing the framework to work with records in the cloud, rather than syncing via files. You should ignore it if you are new here. It relates to changes quite a long way in the future.

Drew

On 17 Jun 2014, at 18:25, Aaron Abt notifications@github.com wrote:

So, I'm confused, is a Parse.com backend support?

—
Reply to this email directly or view it on GitHub.

[Alydyn]

@drewmccormack thank you for the prompt response. That is what I suspected.

-Aaron

[fatuhoku]

This is of great interest to me, and many other Parse users, because syncing data to and from the Parse backend is notoriously manual and labour intensive right now, no matter what APIs they have provided. Yet, their offering is compelling, as you get so much for free: Push, Configuration, Analytics, Data (querying, mainly).

Actually it's far more useful to treat Parse as a peer than to treat it as a file store for holding your transaction logs, because storing transaction logs on Parse won't give you meaningful Data querying capability, or Analytics.

Its database backend is capable of modelling Core Data entities, relationships etc. closely (there are efforts like FTASync to sync the two, but that particular solution hasn't proved to be bulletproof).

Treating Parse as a peer has its problems.

1. Ensembles requires that the data stores sync asynchronously. This means that a mediating file store, such as Dropbox or iCloud is still likely to be a component, thereby complecting the system.
2. iDevices often want to hold a very limited subset of the data available on the backend. Ensembles does not support subset syncing at present (think of Dropbox Selective Sync).

There's solutions:

1. Getting Parse to run a Cloud Code job that performs merge every so often (say, once every minute)
2. ... implement Selective Sync on Ensembles.

The second is a non-trivial, but incredibly useful problem that would be the next logical step for Ensembles.

Parse also has ACLs, which control user data access permissions (obviously...). Controlling this is interesting...

So am I right in saying that Ensembles + Parse isn't really a good idea right now?

[drewmccormack]

Correct. Right now, the two are not a great match.

Ensembles doesn't provide selective sync, and I don't really plan to support it, because when I think it through, it becomes a complex and ugly solution. (Eg. think about what happens to relationships between synced and unsynced objects.)

I think you are much better simply partitioning your data yourself between two Core Data stores, and just syncing up one of them. That is what I am planning to do in my own app. You can do this right now.

I am still not sure what the best would be for entity stores like Parse. You could write server code and have them be a true client, but this would require custom server side code for each service, and would exclude pure cloud stores (e.g. CloudKit). Or you could get the client to update the cloud data, but then the cloud service would not be a true peer, and would be read only (e.g. you couldn't have a web interface that mutates the data).

[erndev]

Hi @drewmccormack

Revisiting this old thread, i had a question about.
Recently, Ensembles has included CloudKit support, which works more or less like Parse (both being record-based instead of file based),
Based on your experience implementing it, do you think now Parse could be an option as a store backend?

it would be a great option for Mac apps that require syncing, but do not want to be in the Mac App Store.

cheers

[drewmccormack]

Yes, Parse could certainly be used. Note that Ensembles doesn't work directly with the CloudKit/Parse records. Instead it just uses the records to store blobs of data, i.e. files. So it uses it more like a file store than the way it was intended to be used.

But yes, you could quite easily take the CloudKit backend, and rewrite it to work with Parse calls instead. If you want to try it yourself, I am happy to offer guidance, but I don't really have time to do this at the moment.

Dropbox Core API is not a bad option if iCloud is off limits.

[erndev]

great! i am working on a mac app, and will definitely use ensembles for syncing.
when it's ready to implement syncing, i'll give it a go and will try to add parse support.

thanks!

[drewmccormack]

Sounds great!
Like I said, when you come to adding Parse, I strongly recommend just copying CDECloudKitFileSystem, and adapting that with calls to Parse instead.