hi michael
On 11.4.12 16:41, Angela Schreiber wrote:
hi
thinking about how to implement the various JCR level operations
that are beyond regular item modification, i found that IMO
will face at least the following 4 types of writing that would
from a oak-api point of view may just look like item state
modifications:
a) Regular JCR Item Modification [...]
b) Special JCR Item Modification [...]
c) Non-Transient JCR Item Modifications [...]
d) Non-Transient Special Item Modification [...]
when looking at the current oak-api and the NodeStateEditor i
don't see how we would currently be able to distinguish these
different types.
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.
that looks really wrong to me. the way i think of the oak-api
is that i obtain the connection from oak-api upon Repository.login
and it would be used for the communication for the lifespan of the
JCR session obtained. retrieving another connection is definitely
not what i am looking for as it would require separate
authentication. that doesn't make sense to me.
Regarding the "special modifications" we still need to come up with a
way to handle those. They should IMO also be done through the
Connection, NodeEditor, etc. interfaces which might need to be tweaked
accordingly.
as stated before i have the impression that this would need to
be reflected on the API.
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.
well... but in fact we would probably want to distinguish between
transient operations that mark the associated JCR items modified/new
until Session.save() is call, whereas all kind of workspace
operations would never have that effect.... figure out the workspace
operation fails during validation on oak-core. there should by
no means a 'modified' flag being pending on the corresponding
jcr items... we didn't that in the early stages of jackrabbit-core
(as long as we had no real access control) and it didn't work.
kind regards
angela
Michael
kind regards
angela
