On 11/25/06, Nicolas <[EMAIL PROTECTED]> wrote:
Hi Stefan,
On 11/25/06, Stefan Guggisberg <[EMAIL PROTECTED]> 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 !!
