jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: Different types of 'item modification' on oak-jcr (and oak-api)
Date Thu, 12 Apr 2012 18:27:20 GMT

On 12.4.12 19:05, Angela Schreiber wrote:

>>> currently, i simply didn't find how i was able to do that
>>> in a reasonable (simple) way and whether that really would
>>> do, what i wanted it to do.
>> editor.addNode("priv-root")
> but that one already exists... i don't want to add it. but
> re-reading the docu: "does nothing if it exists..." *arrrrrgh* :)

We might want to change that agreed. I'm just not sure to what ATM. 
Return the added node or null if it already exists? Return the added 
node or the existing node if it already exists? Return the added node 
and throw if it already exists?

>> privRootEditor = editor.edit("priv-root")
> well. but if it was at a lower level i had to call 'addNode'
> for every single level? and also call 'edit' for every single
> level? ohno...
> i neither want to add nor to edit at those - lets say -
> 5 top-levels until i reach my target node... here the
> methods-names simple not represent what i want to do.
> ... if there was getNodeStateEditor(String path) i just
> had that in one single method call... just an example.

Right. It's a low level interface. It is simple by design. The 
functionality you are missing should best go into some 
helper/convenience classes.

>>> 3) the only way i found to add a next level to that new node state
>>> was NodeStateEditor#edit(String)... was that assumption correct?
>>> if it was i would find that API really troublesome and it looks
>>> like a mixture of different concepts....
>> Which concepts does it mix? It actually separates representation of
>> state from modification of state.
> yes... from the current aspect of the interfaces i just got
> the impression that they are not natural to use which imo
> usually evolves when mixing different things: a simple editor
> for one node that does nothing else mixed up with some sort
> of state-manager functionality... that was my impression.
> so maybe we want to separate state-access-management from
> changelog|set recording functionality... what do you think?

Yes that was my intention. And it should be reflected by 
TransientNodeState and NodeStatedEditor, respectively.

> [...] [skipped explanations] (thanks! i really didn't get it
> from looking at the interfaces...)
>> Well there are no other proposals so far. So this API is still the best
>> we have...
> see above. with your explanations at hand i will take a closer
> look at it again tomorrow... maybe i can come up with some
> suggestions.

That's be great, thanks!


> kind regards
> angela

View raw message