RE: sequence of creation during move command

["Pill, Juergen" <Ju...@softwareag.com>]

Yes, you are right. I was not aware the fact, that the content store is
supposed to store the length. In fact the length is set, when the
contentStore is entered. 
I have changed the TaminoContentStore.create, that it relies now on the
fact, that the descriptor is stored right after the content was successfully
stored. Thanks for the hint!

By the way:  
Are the stores allowed to call themselves in your opinion? E.g. the
TaminoContentStore.storeRevisionContent changes/creates some properties and
then calls the TaminoDescriptorStore to store the descriptor again, see:

     uri.getStore().storeRevisionDescriptor(uri, revisionDescriptor);

Best regards

Juergen Pill



 -----Original Message-----
From: 	Remy Maucherat [mailto:remy@betaversion.org] 
Sent:	Friday, December 29, 2000 9:12 PM
To:	slide-dev@jakarta.apache.org
Subject:	Re: sequence of creation during move command

Quoting "Pill, Juergen" <Ju...@softwareag.com>:

> Hello,
> 
> I would like to suggest to change the sequence of creation of descriptor
> and
> content in following way in the class ContentImpl
> 
> 1) first create the descriptor
> 2) second create the content

That is not that easy to change.
The content store is supposed to set the content length in the descriptor,
so 
that's why the descriptor is stored after the content.

The ContentStore.createRevisionContent
        (Uri uri, NodeRevisionDescriptor revisionDescriptor, 
         NodeRevisionContent revisionContent)
gets the associated revision descriptor as a parameter, so you should be
fine 
(right ?).

Remy

Re: sequence of creation during move command

[Remy Maucherat <re...@apache.org>]

> Yes, you are right. I was not aware the fact, that the content store is
> supposed to store the length. In fact the length is set, when the
> contentStore is entered.

I changed the contract of the ContentStore to make it more flexible. I
didn't advertise the change much, except in the commit message and the
javadoc, which is probably why you had missed it.

> I have changed the TaminoContentStore.create, that it relies now on the
> fact, that the descriptor is stored right after the content was
successfully
> stored. Thanks for the hint!
>
> By the way:
> Are the stores allowed to call themselves in your opinion? E.g. the
> TaminoContentStore.storeRevisionContent changes/creates some properties
and
> then calls the TaminoDescriptorStore to store the descriptor again, see:
>
>      uri.getStore().storeRevisionDescriptor(uri, revisionDescriptor);

Normally, that kind of call is only used in the core and the helpers. In the
future (a long time from now), the way the store is accessed *may* change.
That's not that much of a problem, as it will probably be quite easy to
adapt (if any modifications are needed at all).
Also, you have to be careful about not creating security holes (since you
have direct access to all the objects).

Remy