I've been thinking about this recently, with regard to migrating content schemas across versions of the client application, but the same issues apply. One thing that's hard to see how to do effectively is how to do this export / import thing with a repository containing version histories.
The spec implies that version histories can be exported and imported in the same way as normal workspaces, but is vague about any details: "The serialized content of the source version storage can be deserialized as "normal" content on the target repository, but it will not actually be interpreted and integrated into the repository as version storage data unless it is integrated into or used to replace the target repository's own version storage. Methods for doing this kind of "behind the scenes" alteration to an existing version storage (whether based on the serialized version storage of another repository, or otherwise) are beyond the scope of this specification." Has anybody put any thought into this and had any ideas around how to approach it? Cheers, Miro -----Original Message----- From: Jukka Zitting [mailto:[EMAIL PROTECTED] Sent: 15 March 2006 13:18 To: [email protected] Subject: Re: mixin property and ConstraintViolationException Hi, On 3/15/06, Alexandru Popescu <[EMAIL PROTECTED]> wrote: > Many thanks for describing the version policy. It makes a lot of sense. And > I've been also thinking about the export/import functionality as the single > standard way of assurin content upgrades. Though, this task can be really > tedious considering a very very big repository. Add to this some binary > content, and I am quite sure that the export/import would need more than 4Gb > of RAM for creating and writting the XML, or a very good strategy to slice > the content. It is possible to stream the XML imports and exports using SAX events so we can do that even with moderate RAM requirements, but you are right in that the XML format is probably not the optimum alternative for large repositories. The PersistenceManager abstraction makes it a lot easier for us to maintain backwards compatibility for stored content as it is possible to keep the old persistence managers around if we want to introduce structural changes or other improvements to the storage formats. Thus the upgrade issue should mostly affect situations where you want to migrate your content to a persistence manager that is more optimized to your requirements. This is something that we haven't faced yet, but once we do, it might be useful to create a lower-level persistence manager to persistence manager content migration tool. BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
