jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Miro Walker" <miro.wal...@cognifide.com>
Subject RE: mixin property and ConstraintViolationException
Date Thu, 16 Mar 2006 12:23:22 GMT
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:jukka.zitting@gmail.com] 
Sent: 15 March 2006 13:18
To: jackrabbit-dev@incubator.apache.org
Subject: Re: mixin property and ConstraintViolationException

Hi,

On 3/15/06, Alexandru Popescu <the.mindstorm.mailinglist@gmail.com>
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/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development

Mime
View raw message