We need generic/generated functions for data export and import.

Backing up the database only is not very satisfactory; if the code of an application is lost, it may not be easy to reconstruct the objects.

A JSON representation may be more appropriate.

Also for this application it would be useful to have a notion of containment in data models, since it would provide clear data units.

Submitted by Eelco Visser on 17 September 2012 at 17:41

This seems very similar to what we are developing for web services and synchronization with mobile clients, the mobile client is an example of such a new application that doesn’t know about the underlying server-side database.

The argument here is not very convincing, compared to backing up a large database, backing up the application code is trivial. Also, if you would lose your application (source and binary) code, you wouldn’t have these generated export functions either…

I do agree that we should develop better backup solutions, because simply backing up whole databases with mysqldump does not scale. Speed, backup size, and integration with affordable cloud storage are important things to address.

Yes, I was also thinking about the web service interface.

The point is that it should be possible to provide an export functionality that allows users to get their data out of an application. Not in the form of a slice of a database, but in more logically organized objects.

The JSON provided by the web services is probably a good starting point.

It could give a startpoint, or at least the toJSON functionality could be a helpfull start,

However probably the services will be not really usefull itself, the toplevel structure could be problamatic in this case and gives overhead.

A better way to do this is just do a Entity.all() and foreach loop to transform it to JSON.
The mapping for mobl could/will be probably different.

Import will probably need a more advanced algorithm.