Re: SPI: setValue vs addProperty

[Angela Schreiber <an...@day.com>]

Julian Reschke wrote:
> Hi,
> 
> currently SPI Batch distinguishes between adding a property, and setting 
> the value of a property. In JCR however, this distinction does not exist.

> This test will only pass if SPI's Batch.addProperty actually behaves the 
> same way as setValue, meaning overwriting an existing property.
> 
> Questions:
> 
> 1) Should we update the Javadoc to clarify that this is what it is 
> expected?

yes.

> 2) Should we remove one of the signatures, because the distinction 
> wasn't useful after all?

rather not.
you shouldn't be able to modify the value of a property that
doesn't exist any more... that might happen if the client
is not up-to-date.
however the spi-correspondence of Node.setProperty (means: add
the property if missing or change its value if it exists)
should work then.

angela

Re: SPI: setValue vs addProperty

[Angela Schreiber <an...@day.com>]

Julian Reschke wrote:
> Angela Schreiber wrote:
> Ah, you mean: 
> - addProperty should succeed even though the property already exists, but

in which case it is equivalent to setValue.

> - setValue should continue to fail when the property does not exist yet?

... (rather) doesn't exist any more... because otherwise
you would (hopefully) never get the corresponding jcr-Property.

maybe i'm wrong... but that's how i would define the distiction
between Node.setProperty and Property.setValue assuming your
jcr-api is on client.

but, honestly, i didn't check if jcr2spi behaves according to
that. and i don't remember that the spec explicitly defines
the special situations that might occur in the client
environment.

angela

Re: SPI: setValue vs addProperty

[Julian Reschke <ju...@gmx.de>]

Angela Schreiber wrote:
 > ...
>> Questions:
>>
>> 1) Should we update the Javadoc to clarify that this is what it is 
>> expected?
> 
> yes.
> 
>> 2) Should we remove one of the signatures, because the distinction 
>> wasn't useful after all?
> 
> rather not.
> you shouldn't be able to modify the value of a property that
> doesn't exist any more... that might happen if the client
> is not up-to-date.
> however the spi-correspondence of Node.setProperty (means: add
> the property if missing or change its value if it exists)
> should work then.

Ah, you mean:

- addProperty should succeed even though the property already exists, but

- setValue should continue to fail when the property does not exist yet?

BR, Julian