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 15:46:33 GMT

Thinking a bit more about this, what about introducing the concept of a 
"system editor", which could be used to modify "special items"? While 
the details needs to be sorted out, the general idea is like this:

A "system editor" is an instance of a NodeStateEditor that can modify 
"special items". Normal node state editors can't modify "special items". 
A "system editor" is obtained from a connection similar to how normal 
node state editors are obtained.

In oak-jcr system editors could be used to accumulate changes which 
should dispatch on save and to write changes which need to be dispatched 
immediately (much like NodeStateEditor is currently used). That is, 
modifications stemming from JCR API calls (i.e. addNode) would dispatch 
through a normal node state editor while other modifications (like 
registering a privilege) would dispatch through a "system editor".

Some details we need to sort out are:

- How exactly is a "system editor" obtained? I see currently two ways: 
either add a method to Connection or a parameter to 
Connection.getNodeStateEditor()

- What exactly are "special items". We need a way to mark/encode them in 
the underlying storage model.

Michael


On 12.4.12 15:03, Michael Dürig wrote:
>
>
> On 12.4.12 13:13, Angela Schreiber wrote:
>> well, i still don't see how/where you plan to implement
>> the notion of transient modification.
>>
>> in other words to make it clear (in case it isn't):
>> how do i change protected items in oak-jcr such that the items
>> are marked modified and the session has pending transient changes?
>> and such that i don't have to use the JCR API methods, which in
>> this case from my understanding are 'invalid'?
>>
>> so, how do we make sure that
>> Session#hasPendingChanges
>> Item#isNew
>> Item#isModified
>> never return true in case the workspace operation fails on the oak
>> api for constraint or access violation and on the other hand
>> assert that all kind of transient modifications really trigger
>> the flags to be set?
>>
>> i couldn't follow you here since those methods are not implemented.
>
> That's because this is not read yet. There is no specific plan. We need
> to come up with a way to implement this. That's all.
>
>
>> let's first define how to distinguish transient modifications.
>> i think that is the special case here from a oak-api perspective.
>
> Ack.
>
>
>>> I think the next steps should be:
>>>
>>> 1. Validate my claim from above re. workspace operations
>>
>> what was your claim? can't follow you here.
>
> That workspace ops can be implemented using my changes from rev.
> 1325159. This is done by now. See OAK-63.
>
>
>>> 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.
>>
>> well, your approach of having a separate editor for workspace
>> operations already goes into the direction of separating
>> different change-sets. that was one thing i was wondering about.
>
> Currently I use one editor for the session which represents all
> transient changes done through JCR. For modifications which need to be
> dispatched immediately one can obtain a separate editor from the
> connection. Much like I do for Workspace.copy and Workspace.move.
>
>>
>> IMO we we can basically use the same behavior for registering a
>> node type and an namespace or a privilege under /jcr:system/something...
>> (the latter was actually what brought up my
>> questions). oak-core was in any case in charge of validating the
>> changes individually and detecting the distinction between
>> a change to the node type registry or just a workspace. so,
>> maybe we can use the same mechanism.
>
> Yes I think that should work.
>
> AFAICT the remaining questions are all about handling of "special items"
> taking into account modification state of items and session, visibility
> and editability of such items, dispatching (i.e. on session save or
> immediate) of such items, ...
>
> Michael
>
>
>>
>> what do you think?
>> angela
>>
>>
>>> 3. In the process come up with better names.
>>
>>
>>
>>> Michael
>>>
>>>>
>>>> kind regards
>>>> angela
>>>>> Michael
>>>>>
>>>>>>
>>>>>> kind regards
>>>>>> angela
>>>>>>

Mime
View raw message