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 09:13:36 GMT

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.


> kind regards
> angela
>> Michael
>>> kind regards
>>> angela

View raw message