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 16:47:24 GMT
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

> 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