jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicolas " <nto...@gmail.com>
Subject Re: Import in versionStorage
Date Sat, 25 Nov 2006 18:40:21 GMT
On 11/25/06, Stefan Guggisberg <stefan.guggisberg@gmail.com> wrote:
> i can only think of one legitimate use case that justifies low-level
> operations
> directly on meta data that circumvents the api calls, and that's the
> repository
> restore operation.
> of meta data

I partially agree. The low-level operations should be called only by restore
operations but the restore operation can be slightly different than the one
I currently do. I mean let's think of this low level class as a way for the
backup tool to restore the versioning but also to allow other use cases we
don't currently envision (ie: a way to override selectively the versioning
system, Frederique's system,...).

Anyway, on this specific point, the restore operation of the backup tool
would solve Frederique's problem, so let's see how things are going after
this code part is rewritten and released.

e.g. a binary backup data format because the system view serialization
> format is hardly efficient.

The design of the backup tool allows format to be changed easily. You call a
backup class for each resource you want to backup (defined in the xml conf
file), so we can envision having two formats: a "durable format'" and an
efficient one. I think it would bring the best of both world and let admin
decide according to their needs.

On another hand, if everyone thinks a binary backup format is better than a
human readable and JCR conform, one, I will work in this direction and won't
need to refactor WorkspaceImporter.

the restore could e.g. be implemented like BatchedItemOps,
> either by extending or even create a new class from scratch.

Actually, I also need BIO and cannot extend it (see code in JIRA you'll
understand). The problematic is actually quite close to the current
WorkspaceImporter issue.

Creating a new class from scratch was exactly what I did during GSOC but it
overlaps significantly with the current classes. This is one of the reason
they didn't get committed and are still in JIRA. So please, let's agree on

1/ Either I can simply rewrite some parts of the current backup tool (it
works but I would like to rewrite some lines for readibility since I
progressed a lot in Java those past few months). This means you would have
to commit a few classes overlapping significantly with the existing ones
(and with quite close codes actually).

2/ Or keep working as planned: use this as an opportunity to make some
classes more flexible. Refactor them and then commit the backup tool (which
takes of course longer).

Both approaches have pro and cons. I don't feel I am the right person to
choose the approach: I don't have all the knowledge you have on Jackrabbit
(technical and historical).

If I understand correctly your previous email, you would go for approach 1.
Am I correct?

PS On a sidenote, currently I can dedicate only an afternoon a week to
finish this.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message