jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: Different types of 'item modification' on oak-jcr (and oak-api)
Date Wed, 11 Apr 2012 18:53:28 GMT

> On Wed, Apr 11, 2012 at 6:30 PM, Michael Dürig<mduerig@apache.org>  wrote:
>> The current API should be able to cope with transient modifications and
>> non-transient modifications. The latter can be done by obtaining a new
>> connection just for those changes.
> IMHO a separate connection shouldn't be needed for that, just a
> separate commit() against the same base state.

well... but my problem still would not be addressed:

first, in one case i wished to make changes on some sort of lower
level state in oak-jcr to be recorded as transient modifications
(the corresponding item to be marked new or modified) and in another
case i definitely would want to avoid that... the use case for those
lower-oak-jcr level transient modifications actually is that i dislike
the way we handle that in jackrabbit-core and at the same time i am
sure that we need to enforce the check for protected items
on oak-jcr. reason: if we want to represent such modifications as
regular item-changes on oak-api instead of having a separate API
defined for it, we won't be able to enforce the protected check on
oak-api any more... it would just be responsible for all the other

second, maybe i even had transient modifications pending and at the
same time would want to register a new node type but not committing
the transient modifications and i don't see a compelling reason
why that wouldn't be possible.

i was looking today how the Item.isNew() and isModified() flag is
set and found that this is missing altogether (though i thought
i had seen that before)... so, it looks to me that the current API
(or implementation) is missing some fundamental distinctions here.

>> The name reflects "transient" from JCR and should emphasis the fact that
>> instances of this class are - in contrast to NodeState - not Immutable.
>> However, we could rename this not MutableNodeState or something different if
>> you prefer.
> I'd rather not call such an interface *NodeState, as that suggests
> something that ISA NodeState, and thus a specialization, not a
> generalization of the supertype contract.

yes, and maybe this was exactly the place to introduce a distinction
between something that is transiently modified and some sort of
lower-level modified node 'state' that is just used to transport
changes to oak-api for validation.

> BR,
> Jukka Zitting

View raw message