Re: Import in versionStorage
On 11/27/06, Nicolas [EMAIL PROTECTED] wrote: Hi Florent, What you describe is one of the backup tool use case. I am adding the last touch to it so it can be committed it by hopefully next week (there is jut a well, that might be a bit overoptimistic... cheers stefan few home cleaning tasks to perform). If you need it faster, please contact me privately so I can tell you which classes you need to integrate in JR. You can easily set up your own backup (ie no namespace backup) and restore it in a blank repository. (I will work after on merging code duplicate within some parts of the core.) BR, Nico my blog! http://www.deviant-abstraction.net !! On 11/27/06, Florent Guillaume [EMAIL PROTECTED] wrote: To expand a bit on Frédérique's use case: she wants to import lots of data from another sql-based repository. This includes creating version data, and controlling the VersionHistory and Version object's UUIDs (because these UUIDs are referenced by properties in other objects). Using checkin/checkout for that means we lose the UUID consistency, and have to post-process some of the properties as we do the import. So a system view import of the version storage would really be nice. Florent
Re: Import in versionStorage
Hi Florent, What you describe is one of the backup tool use case. I am adding the last touch to it so it can be committed it by hopefully next week (there is jut a few home cleaning tasks to perform). If you need it faster, please contact me privately so I can tell you which classes you need to integrate in JR. You can easily set up your own backup (ie no namespace backup) and restore it in a blank repository. (I will work after on merging code duplicate within some parts of the core.) BR, Nico my blog! http://www.deviant-abstraction.net !! On 11/27/06, Florent Guillaume [EMAIL PROTECTED] wrote: To expand a bit on Frédérique's use case: she wants to import lots of data from another sql-based repository. This includes creating version data, and controlling the VersionHistory and Version object's UUIDs (because these UUIDs are referenced by properties in other objects). Using checkin/checkout for that means we lose the UUID consistency, and have to post-process some of the properties as we do the import. So a system view import of the version storage would really be nice. Florent
Re: Import in versionStorage
Hi, On 11/25/06, Stefan Guggisberg [EMAIL PROTECTED] wrote: On 11/24/06, SADAUNE Frederique (EURIWARE) [EMAIL PROTECTED] wrote: I want to import documents in Jackrabbit's repository but I don't manage to import their different versions. Is there another way than checkout(),checkin() ? The backup tool sends a ConstraintViolationException due to the node's protected property when trying to import directly on the versionStorage. unless there is a really compelling reason i would strongly discourage to manipulate meta data directly and rather use the appropriate api methods. after all there's a reason why the meta data is 'protected'. I think Frederique's concern is valid, there needs to be a way to restore not only current versions but also the version histories of nodes from a backup. This is the key reason for extending the WorkspaceImporter functionality to meet the needs of Nicolas' backup tool. The checkin/checkout methods are not expressive enough to fully restore the version history of a node. For example there is no way to control the jcr:created timestamps of the checked in versions. BR, Jukka Zitting
Re: Import in versionStorage
Hi, On 11/25/06, Stefan Guggisberg [EMAIL PROTECTED] wrote: i interpreted frederique's use case as 'importing' new documents, not restoring a jackrabbit backup. i might have got him wrong though. My understanding was that he wants to import not only the documents but also their version histories. It could be because of backup/restore, migrating from another repository, or some other reason. In any case we don't currently offer enough functionality to achieve the use case. wrt WorkspaceImporter: i agree that it's not suited for restoring meta data, it was not designed for this use case and IMO it's the wrong approach as i've pointed out repeatedly. 'import' and 'restore' operations have IMO completely different semantics. I hear you. :-) My position is that they are close enough (especially in Nicolas' design that's based on the XML serializations) that sharing code makes sense, as long as the details are sorted out properly. I agree that it might be worth exploring also alternatives to the current backup/restore design. For example a specialized import/export interface that works directly at the PersistenceManager level could simplify and considerably speed up things at the expense of adding another low-level dependency and leaving all the consistency issues open. BR, Jukka Zitting
