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 17:35:16 GMT

On 12.4.12 17:47, Angela Schreiber wrote:
> 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.

That's exactly what my proposal tries to solve. You would use the 
"system node editor" for that.

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

privRootEditor = editor.edit("priv-root")
privRootEditor.setProperty("one", ...)
privRootEditor.setProperty("two", ...)

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

That's easy to change and we probably should.

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

Which concepts does it mix? It actually separates representation of 
state from modification of state.

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

This could admittedly be clearer. Connection.commit() accepts any editor 
and will apply all changes which have been done to the root editor from 
which that editor originated. The reason for that is, that each editor 
also represent the private branch which was forked off at the time 
Connection.getNodeStateEditor() was called. We could of course make this 
more explicit by introducing a Branch class which would then be returned 
from NodeStore.branch() and which would contain methods for obtaining 
NodeStateEditor instances. However I feared that would be called 
over-engineered again...

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

Well there are no other proposals so far. So this API is still the best 
we have...


> 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

View raw message