jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg" <stefan.guggisb...@gmail.com>
Subject Re: Import in versionStorage
Date Sat, 25 Nov 2006 17:54:01 GMT
On 11/25/06, Nicolas <ntoper@gmail.com> wrote:
> Hi Stefan,
>
> On 11/25/06, Stefan Guggisberg <stefan.guggisberg@gmail.com> wrote:
>
> > wrt WorkspaceImporter: i agree that it's not suited for restoring meta
> > data,
> > it was not designed for this use case and IMO it's the wrong approach
> > as i've pointed out repeatedly. 'import' and 'restore' operations have IMO
> > completely different semantics.
>
>
> Actually the backup tool is not using WorkspaceImporter in the backup tool.
> We use a class heavily based on it with some changes disseminated throughout
> all the code. It is a bad solution and I acknowledge it.
>
> The idea is to extract out of WorkspaceImporter a base class (but first it
> needs refactoring). We would then use it for the WorkspaceImporter and a new
> RestoreImporter class. This way the common code would not be duplicated but
> each class would be able to express their own semantics.
>
> As Frederique's use case points it out, I believe there is a need for those
> kind of low level operations and not only for the backup tool.

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

>
> What other approach do you please suggest?

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

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

cheers
stefan

>
> BR,
> Nico
> my blog! http://www.deviant-abstraction.net !!
>
>

Mime
View raw message