[Owncloud] App Data Migration

Bartek Przybylski bart.p.pl at gmail.com
Mon Mar 5 08:52:12 UTC 2012


This is only a proposition but if we assume that version changes only
when scheme change there shouldnt be any problem ;)

bartek

2012/3/5 Achim Bohnet <ach at mpe.mpg.de>:
> Am Samstag, 3. März 2012, 23:06:56 schrieb Bartek Przybylski:
> [...]
>>
>> Tom also ask me to provide xml example for bookmarks app, so here it is :
>>
>> <migration app_version="0.2">
>
> May I suggest a data model version instead of app version.
> Maybe the older app v0.4 can import data from new v0.7 as long
> as the data model has not changed.
>
> Achim
>
>>   <db>
>>     <table name = "*PREFIX*bookmarks">
>>       <field name="id"/>
>>       <field name="url"/>
>>       <field name="title"/>
>>       <field name="user_id" user_id/>
>>       <field name="public"/>
>>       <field name="added"/>
>>       <field name="lastmodified"/>
>>       <field name="clickcount"/>
>>     </table>
>>     <table name="*PREFIX*bookmarks_tags">
>>       <field name="bookmark_id" relates_to="**PREFIX*bookmarks.id" />
>>       <field name="tag" />
>>     </table>
>>   </db>
>> <!--
>>    <files>
>>      <dir path="path_to_export"/>
>>      <file path="file_to_export"/>
>>    </files>
>> -->
>> </migration>
>>
>> table tag doesn't have to contain all fiels, but only those to migrate
>> (they must be null possible)
>> in case of questions to my idea don't hesitate to comment and ask
>>
>> bartek
>>
>> 2012/3/3 Tom Needham <tom at owncloud.com>:
>> > Could you describe this process in more details ? then we could look
>> > for enhancements ;)
>> >
>> >
>> > OK. Apps will provide an import and export function. See and examples for
>> > the bookmarks app
>> > here: http://gitorious.org/owncloud/owncloud/blobs/691103acd5aad2673b63757
>> > 26ba24fb56e88451b/apps/bookmarks/lib/migrate.php
>> >
>> > 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.
>> >
>> > 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).
>> >
>> > 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 ;)
>> >
>> > Also, I found a function that will format the json output so that it is
>> > still human readable.
>> >
>> > Thanks,
>> > Tom
>> >
>> > Tom Needham
>> > tom at owncloud.com
>> >
>> >
>> >
>> > 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 <tom at owncloud.com>:
>> >
>> > 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.
>> >
>> >
>> > Cheers,
>> >
>> > Tom
>> >
>> >
>> >
>> > Tom Needham
>> >
>> > tom at owncloud.com
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> >
>> > Owncloud mailing list
>> >
>> > Owncloud at kde.org
>> >
>> > https://mail.kde.org/mailman/listinfo/owncloud
>>
>> _______________________________________________
>> Owncloud mailing list
>> Owncloud at kde.org
>> https://mail.kde.org/mailman/listinfo/owncloud
> --
>  To me vi is Zen.  To use vi is to practice zen. Every command is
>  a koan. Profound to the user, unintelligible to the uninitiated.
>  You discover truth everytime you use it.
>                                      -- reddy at lion.austin.ibm.com
>
> _______________________________________________
> Owncloud mailing list
> Owncloud at kde.org
> https://mail.kde.org/mailman/listinfo/owncloud



More information about the Owncloud mailing list