Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of anchela@adobe.com designates
 64.18.1.23 as permitted sender)
Message-ID: <4F87071C.2010205@adobe.com>
Date: Thu, 12 Apr 2012 18:47:24 +0200
From: Angela Schreiber <anchela@adobe.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
 rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: <oak-dev@jackrabbit.apache.org>
Subject: Re: Different types of 'item modification' on oak-jcr (and oak-api)
References: <4F85A60E.3020709@adobe.com> <4F85B19C.5030601@apache.org>
 <4F8688B1.5050206@adobe.com> <4F869CC0.8030907@apache.org>
 <4F86C6F7.20601@adobe.com> <4F86E0C7.7060901@apache.org>
 <4F86F8D9.6010007@apache.org>
In-Reply-To: <4F86F8D9.6010007@apache.org>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit

hi michael

> 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.

not sure if i like that. actually i rather don't :)

IMO those special content are just regular items from oak-JCR point
of view, while oak-CORE would need to have knowledge of all kind of 
special items anyway. that starts from jcr:primaryType and goes to
nodes of type jcr:nodeType.

what i am actually looking for (and had a quick discussion looking
at my real privilege-registration example) was probably some sort
of changelog/changeset and second some way of adding state
modifications independent from accessing jcr items.

example: registering a new privilege could for example consist of

- add a new node state underneath the dedicated priv-root
- add 2 properties to that new node state
- maybe there was even an additional next-level child node states.

currently, i simply didn't find how i was able to do that
in a reasonable (simple) way and whether that really would
do, what i wanted it to do.

some issues i found with the API so far

1) tried to use your workspace.copy example.... but
    to connection.getNodeStateEditor i can't pass
    a path but only a state other than the root node
    that i simply don't have access to if i don't want to
    use the current session.....
    the currentroot was not the right location to add content.
    -> see also my comment on NodeStateEditor#edit below

2) i find it odd that NodeStateEditor#addNode doesn't
    return me the new node state.

3) the only way i found to add a next level to that new node state
    was NodeStateEditor#edit(String)... was that assumption correct?
    if it was i would find that API really troublesome and it looks
    like a mixture of different concepts....

4) why wasn't there another way to access the new child node state?
    or the original node state?
    i just got an editor but there is no way to get from editor
    to node state as far as i saw.

5) connection commit takes a NodeState editor.
    could that be an editor other than the root-node editor?
    if not, why? and how/where do you control that?
    and if yes: why can't i access the that other non-root-editor then?

those are just a couple of comments... after all the current API doesn't
look very consistent and satisfying to me.

kind regards
angela


> 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
>>>>>>>