Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <456B1E43.4040105@nuxeo.com>
Date: Mon, 27 Nov 2006 18:20:03 +0100
From: Florent Guillaume <fg@nuxeo.com>
User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909)
MIME-Version: 1.0
To: dev@jackrabbit.apache.org
Subject: Re: Import in versionStorage
References: <A1179DDA71806A42ACF4134591D6F5A31A79F2@bfreequmx01.bdom.ad.corp>
	 <90a8d1c00611250053k73845e9en2ee83d9e508e497d@mail.gmail.com>
	 <510143ac0611250253n68c95851x186d4d48758a81db@mail.gmail.com>
	 <90a8d1c00611250355x12529dd8vada59901e29b51c7@mail.gmail.com>
	 <fcbb46050611250456k57d8ab6fv6fb8f715b88b1367@mail.gmail.com>
 <90a8d1c00611250954qad149f5q5cea999c0416e824@mail.gmail.com>
In-Reply-To: <90a8d1c00611250954qad149f5q5cea999c0416e824@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Stefan Guggisberg wrote:
> 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

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