Stefan Guggisberg wrote:
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
To expand a bit on Frédérique's use case: she wants to import lots of data
from another sql-based repository. This includes creating version data, and
controlling the VersionHistory and Version object's UUIDs (because these
UUIDs are referenced by properties in other objects). Using checkin/checkout
for that means we lose the UUID consistency, and have to post-process some
of the properties as we do the import.
So a system view import of the version storage would really be nice.
Florent
