Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4F86E0C7.7060901@apache.org>
Date: Thu, 12 Apr 2012 15:03:51 +0100
From: =?ISO-8859-1?Q?Michael_D=FCrig?= <mduerig@apache.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:11.0) Gecko/20120327 Thunderbird/11.0.1
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>
In-Reply-To: <4F86C6F7.20601@adobe.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit


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