Am 23.04.2008 um 13:23 schrieb Julian Reschke:
Well, the normal update cycle is *getting* the content, modifying
it, then writing it back. To be useful, that's the sequence of
operations that needs to be supported, right?
Yes, from the user point of view. But the Jackrabbit implementation is
copy-on-write, so technically the transient space is "touched" in the
modifying-it step.
I've tried it, and it doesn't seem to make a difference.
Well, at least some consistency here ;-)
Another reason might be that you are using a binary property
("jcr:data"). These are handled differently inside Jackrabbit
because they tend to be large and are stored in the DataStore for
example. (Although this should only apply for larger ones...).
Maybe you could try to test with a simple DOUBLE property instead.
I can try that, but believe me, that wasn't the goal of this exercise.
Would be cool if you could try that too.
Shouldn't we have test cases for this kind of stuff???
True! Your code is a good test case. (Binary and double etc.
properties should probably tested separately)
@All: Is this a bug? Are there any test cases? WDYT?
Alex
--
Alexander Klimetschek
[EMAIL PROTECTED]
>> Day JCR Cup 08 | Win a MacBook Pro: http://dev.day.com/ <<
