hi
On Wed, Apr 11, 2012 at 6:30 PM, Michael Dürig<[email protected]> 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
validation.
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.
regards
angela
BR,
Jukka Zitting
