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
