On 12.4.12 8:48, Angela Schreiber wrote:
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.
See my reply to Jukka and my related commit of rev. 1325159.
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.
Yes, that's what I said. So let's come up with a way to do that.
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.
Workspace operation should be doable now with my changes in rev.
1325159. I will try to implement copy and move to validate this.
TransientNodeState turned out to be a bad name for several reasons: 1.
it implies being a NodeState which it isn't, and 2. it implies a one to
one correspondences with transient modifications of JCR items which
seems a too restrictive assumption.
I think the next steps should be:
1. Validate my claim from above re. workspace operations
2. Come up with a way to do "special modifications" following the
general direction sketched by NodeStateEditor et. all. This might
require adding higher level abstractions to the oak API and/or oak-jcr
and might also require changes/tweaks to the current state of affairs.
3. In the process come up with better names.
Michael
kind regards
angela
Michael
kind regards
angela
