jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Klimetschek" <aklim...@day.com>
Subject Re: Handling many versions, disposing/swapping out old ones
Date Mon, 30 Jun 2008 12:57:55 GMT
Cross-posting to dev, because of the versioning storage discussion.

On Mon, Jun 30, 2008 at 8:26 AM, Sven Schliesing
<schliesing@subshell.com> wrote:
> Hi Alex, hi list,
>> Wow, what use case do you have? 30000 sounds like the versions are
>> created by an automated system. Is it equally possible that one of
>> those thousands of old revisions are restored? Or displayed in a
>> whatever kind of version history?
> The versions are indeed created by humans. :) While the users publish new
> content the system creates one version each time. This is needed for legal
> issues. One use case is to get a version from a certain date.
> The customer creating this vast amount of versions is a editorial working
> 24/7. The system is running nearly 1,5 years now. So 50 versions a day is
> quite normal.
> As already mentioned we can't/are not allowed to remove old versions.

Ok, I see, you really have a hard use case there ;-)

> So there would be only the option of swapping out old versions.
> Maybe we could create an additional workspace we use for archiving these
> versions?

The versioning storage is like a separate workspace. The problem is
that with more than 10000 child nodes for a node, Jackrabbit gets
slower, since it is not optimized for that use case. This is true for
nearly all persistence managers, especially for the bundle pms. Since
the version storage uses a flat hierarchy, too, you noticed the

I think you could remove old versions and store them in a different
workspace with a non-flat hierarchy, but you would have to work around
the versioning API to get access to the old versions in that case. Or
even make that visible in the UI, such as calling these versions
"archived" or similar.

A solution in Jackrabbit could mean to change the versioning storage
to use nested nodes instead of a flat hierarchy, although I cannot say
if this is feasible (eg. branches are already nested, I think). What
do other devs think? Valid issue to think about?


Alexander Klimetschek

View raw message