On 03.03.2012 21:48, Tom Needham wrote:
Hi,
I am not sure if I understand which kind of migration are we talking
about here? Is it migrating data from ownCloud version 4 -> 5, given
that the particular app needs database changes? Or are we talking that
somebody wants to migrate the user data from one ownCloud to another,
maybe with different versions? We probably have to deal with both cases
on the longer run...
OK. Apps will provide an import and export function. See and examples for the
bookmarks app here:
http://gitorious.org/owncloud/owncloud/blobs/691103acd5aad2673b6375726ba24fb56e88451b/apps/bookmarks/lib/migrate.php
Thats cool.
When ownCloud needs to export a user, it will run
OC_Migration::export($userid). This will then execute all of the 'export'
functions for apps that have registered as migration providers. Once it
receives data back from these functions it wraps it all up into either XML,
JSON or something along those lines and exports it to a file. When importing,
its pretty much the reverse of this, except each app will be passed its portion
of the export file. It can then run through that and add items back into the
database.
What is $userid? A name? An email? Can't be an database id I guess,
because that will be different on the other system. There needs to be
one unique key to identify a user.
Or is it the id of the currently logged in user, which would limit the
whole functionality to the user level other than an admin scenario who
wants to migrate all his users to another ownCloud.
The backend will do the dirty work to make it easier for devs. For example, on
export it will add in information from the apps info.xml file so this can be
accessed when importing. The backend will also pass a $uid to the import
functions because this may have changed from the original install (because of a
conflict on the new install).
What about apps which handle big amounts of data, such as images,
movies, music, X-ray pictures and such?
The question is how we should export the data? XML, JSON... ? I tried using
JSON this afternoon and it saved a lot of time because apps could just pass an
array structure for their 'export' function and then all the backend has to do
is merge some arrays and run json_encode(). Also creating arrays is much easier
than playing with DOMDocument ;)
I think XML has more tools to check and process the data (XSLT, XPath
etc), but they are not very handy. However that can be a big benefit.
have fun,
Klaas
On 3 Mar 2012, at 20:37, Bartek Przybylski wrote:
Hi Tom!
Could you describe this process in more details ? then we could look
for enhancements ;)
bartek
2012/3/3 Tom Needham<[email protected]>:
Hi All,
So I'm currently doing some work on a backend for app data migration.
Basically apps can register as migration providers (much like they do with
search) and provide and import and export function.
Originally I was planning to use XML as the overall output format but we
just had a chat in IRC and possibly JSON would be easier? Apps could just
provide an array structure on export and be given the same one on import.
The backend will do all the hard work of mashing all the arrays together,
and adding in various other data (app version numbers, owncloud version
number..) and then just run json_encode() and export to a .json file.
What does everyone thing? Thought I'd get your feedback before going ahead
with it.
_______________________________________________
Owncloud mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/owncloud
