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 Thu, 12 Apr 2012 07:48:01 GMT
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
>>

Mime
View raw message