Difference between revisions of "Migration Of Escidoc Data"

From MPDLMediaWiki
Jump to navigation Jump to search
m
 
(2 intermediate revisions by one other user not shown)
Line 1: Line 1:
The goal of the Migration procedure is to transform the Escidoc data created and modified with a certain stable Escidoc-core release to the next stable Escidoc-core release.  
Stable Releases:
Migration procedure also tries to make a transformation of the objects created or modified with one of the developer builds delivered between these two stable Escidoc-core releases, but doesn't warrant the correctness and consistence of the result. Therefore the migration procedure will make a logg entry for every object, created or modified with one of the developer builds delivered between these two stable Escidoc-core releases. The application should care about such objects.
* The goal of the Migration procedure is to transform data representaion (FOXML) between stable releases. A migration tool will be part of each stabe release, which only supports the migration from the last stable release. A skip of stable releases in the update process is not supported for the near future and not recommended. A downgrade is also not supported.
 
Developer releases:
* A migration from or between developer builds are not, and will not be, supported. We highly recommend NOT to use developer builds with productive data.
It might be that a developer builds work quite well with the data representation from the latest stable release, but we give no warranty that it will be able to migrate these data afterwards to the next stable release.
Nevertheless, the migration tool will try to convert data objects from developer builds. An object is left out, with an entry in the log file, if converting fails. You will only find converted data object in the new repository. Each objects which could not be converted automatically has to be migrated without tool support. Each object, which was created or updated with a developer build, gets also a log entry if converting was successful. A successful conversion in such cases is not a proof for data consistency. Therefore the application should check each such converted object.
 
 
[[Category:eSciDoc]]

Latest revision as of 12:43, 5 January 2011

Stable Releases:

  • The goal of the Migration procedure is to transform data representaion (FOXML) between stable releases. A migration tool will be part of each stabe release, which only supports the migration from the last stable release. A skip of stable releases in the update process is not supported for the near future and not recommended. A downgrade is also not supported.

Developer releases:

  • A migration from or between developer builds are not, and will not be, supported. We highly recommend NOT to use developer builds with productive data.

It might be that a developer builds work quite well with the data representation from the latest stable release, but we give no warranty that it will be able to migrate these data afterwards to the next stable release. Nevertheless, the migration tool will try to convert data objects from developer builds. An object is left out, with an entry in the log file, if converting fails. You will only find converted data object in the new repository. Each objects which could not be converted automatically has to be migrated without tool support. Each object, which was created or updated with a developer build, gets also a log entry if converting was successful. A successful conversion in such cases is not a proof for data consistency. Therefore the application should check each such converted object.