You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Angela Schreiber <an...@adobe.com> on 2012/04/11 17:41:02 UTC
Different types of 'item modification' on oak-jcr (and oak-api)
hi
thinking about how to implement the various JCR level operations
that are beyond regular item modification, i found that IMO
will face at least the following 4 types of writing that would
from a oak-api point of view may just look like item state
modifications:
a) Regular JCR Item Modification
- transient modification on jcr items
- example: Node.addNode, Item.remove, Property.setValue etc.
- effect on oak-jcr:
> Item or parent item is modified or new
> Session has pending changes
- effect on oak-api:
> changes are not yet persisted and not visible on oak-api
but only upon Session.save()
b) Special JCR Item Modification:
- transient modifications on jcr items through other API
associated items may e.g. be protected
- example: AccessControlManager.setPolicy, User.changePassword
- effect on oak-jcr:
> Item or parent item is modified or new
> Session has pending changes
- effect on oak-api:
> changes are not yet persisted and not visible on oak-api
but only upon Session.save()
c) Non-Transient JCR Item Modifications:
- workspace level jcr item modifications
- example: Node.checkin, Workspace.clone, Workspace.move
- effect on oak-jcr:
> Item or parent item is neither modified nor new
> Session doesn't have pending changes
> changes are never visible as transient modification
> no Session.save()
- effect on oak-api:
> either changes are directly passed to oak-api or there
exists separate API methods on oak-api to cover these
operations.
d) Non-Transient Special Item Modification:
- workspace or 'repository' level item modifications for
special JCR functionality we may represent as content on
lower levels
- example: registered node types represented as jcr items under
/jcr:system/jcr:nodetypes assuming that registration
was mapped as simple item modification.
- effect on oak-jcr:
> Item or parent item is neither modified nor new
> Session doesn't have pending changes
> changes are never visible as transient modification
> no Session.save()
- effect on oak-api:
> item modifications changes are directly passed to oak-api
and validated, persisted accordingly
when looking at the current oak-api and the NodeStateEditor i
don't see how we would currently be able to distinguish these
different types.
similarly, the TransientNodeState looks in this respect a bit
odd to me as 'transient' and 'state' could be looked at as
controversial concepts.
kind regards
angela
Re: Different types of 'item modification' on oak-jcr (and oak-api)
Posted by Michael Dürig <md...@apache.org>.
On 12.4.12 19:05, Angela Schreiber wrote:
>>>
>>> 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.
>>
>> editor.addNode("priv-root")
>
> but that one already exists... i don't want to add it. but
> re-reading the docu: "does nothing if it exists..." *arrrrrgh* :)
We might want to change that agreed. I'm just not sure to what ATM.
Return the added node or null if it already exists? Return the added
node or the existing node if it already exists? Return the added node
and throw if it already exists?
>
>> privRootEditor = editor.edit("priv-root")
>
> well. but if it was at a lower level i had to call 'addNode'
> for every single level? and also call 'edit' for every single
> level? ohno...
>
> i neither want to add nor to edit at those - lets say -
> 5 top-levels until i reach my target node... here the
> methods-names simple not represent what i want to do.
> ... if there was getNodeStateEditor(String path) i just
> had that in one single method call... just an example.
Right. It's a low level interface. It is simple by design. The
functionality you are missing should best go into some
helper/convenience classes.
>>> 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.
>
> yes... from the current aspect of the interfaces i just got
> the impression that they are not natural to use which imo
> usually evolves when mixing different things: a simple editor
> for one node that does nothing else mixed up with some sort
> of state-manager functionality... that was my impression.
>
> so maybe we want to separate state-access-management from
> changelog|set recording functionality... what do you think?
Yes that was my intention. And it should be reflected by
TransientNodeState and NodeStatedEditor, respectively.
>
> [...] [skipped explanations] (thanks! i really didn't get it
> from looking at the interfaces...)
>
>> Well there are no other proposals so far. So this API is still the best
>> we have...
>
> see above. with your explanations at hand i will take a closer
> look at it again tomorrow... maybe i can come up with some
> suggestions.
That's be great, thanks!
Michael
>
> kind regards
> angela
Re: Different types of 'item modification' on oak-jcr (and oak-api)
Posted by Angela Schreiber <an...@adobe.com>.
hi michael
>> 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.
ok, than maybe i was just confused by the name :)
>> 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.
>
> editor.addNode("priv-root")
but that one already exists... i don't want to add it. but
re-reading the docu: "does nothing if it exists..." *arrrrrgh* :)
> privRootEditor = editor.edit("priv-root")
well. but if it was at a lower level i had to call 'addNode'
for every single level? and also call 'edit' for every single
level? ohno...
i neither want to add nor to edit at those - lets say -
5 top-levels until i reach my target node... here the
methods-names simple not represent what i want to do.
... if there was getNodeStateEditor(String path) i just
had that in one single method call... just an example.
>> 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
>
> TransientNodeState.getChildNode()
but i don't want to have the transient state of the root
nor any other sublevel that i would want to bypass in order
to get to my target node... they can happily stay untouched.
and if i can commit any editor not only the root i don't
know why i had to do all the effort described above. i really
try to be very lazy ;)
>>
>> 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.
cool.
>> 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.
yes... from the current aspect of the interfaces i just got
the impression that they are not natural to use which imo
usually evolves when mixing different things: a simple editor
for one node that does nothing else mixed up with some sort
of state-manager functionality... that was my impression.
so maybe we want to separate state-access-management from
changelog|set recording functionality... what do you think?
[...] [skipped explanations] (thanks! i really didn't get it
from looking at the interfaces...)
> Well there are no other proposals so far. So this API is still the best
> we have...
see above. with your explanations at hand i will take a closer
look at it again tomorrow... maybe i can come up with some
suggestions.
kind regards
angela
Re: Different types of 'item modification' on oak-jcr (and oak-api)
Posted by Michael Dürig <md...@apache.org>.
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.
editor.addNode("priv-root")
privRootEditor = editor.edit("priv-root")
privRootEditor.setProperty("one", ...)
privRootEditor.setProperty("two", ...)
privRootEditor.addNode(...)
>
> 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
TransientNodeState.getChildNode()
>
> 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.
TransientNodeState.getParent()
TransientNodeState.getChildNode()
TransientNodeState.getEditor()
NodeStateEditor.getTransientState()
>
> 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...
Michael
>
> 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
>>>>>>>>
Re: Different types of 'item modification' on oak-jcr (and oak-api)
Posted by Angela Schreiber <an...@adobe.com>.
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
>>>>>>>
Re: Different types of 'item modification' on oak-jcr (and oak-api)
Posted by Michael Dürig <md...@apache.org>.
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
>>>>>>
Re: Different types of 'item modification' on oak-jcr (and oak-api)
Posted by Michael Dürig <md...@apache.org>.
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
>>>>>
Re: Different types of 'item modification' on oak-jcr (and oak-api)
Posted by Angela Schreiber <an...@adobe.com>.
hi michael
>> that looks really wrong to me. the way i think of the oak-api
>> is that i obtain the connection from oak-api upon Repository.login
>> and it would be used for the communication for the lifespan of the
>> JCR session obtained. retrieving another connection is definitely
>> not what i am looking for as it would require separate
>> authentication. that doesn't make sense to me.
>
> See my reply to Jukka and my related commit of rev. 1325159.
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.
>>> Regarding the "special modifications" we still need to come up with a
>>> way to handle those. They should IMO also be done through the
>>> Connection, NodeEditor, etc. interfaces which might need to be tweaked
>>> accordingly.
>>
>> as stated before i have the impression that this would need to
>> be reflected on the API.
>
> Yes, that's what I said. So let's come up with a way to do that.
let's first define how to distinguish transient modifications.
i think that is the special case here from a oak-api perspective.
> Workspace operation should be doable now with my changes in rev.
> 1325159. I will try to implement copy and move to validate this.
i added a check for srcWorkspace not being the current workspace.
> TransientNodeState turned out to be a bad name for several reasons: 1.
> it implies being a NodeState which it isn't, and 2. it implies a one to
> one correspondences with transient modifications of JCR items which
> seems a too restrictive assumption.
see above.
>
> 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.
> 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.
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.
what do you think?
angela
> 3. In the process come up with better names.
> Michael
>
>>
>> kind regards
>> angela
>>> Michael
>>>
>>>>
>>>> kind regards
>>>> angela
>>>>
Re: Different types of 'item modification' on oak-jcr (and oak-api)
Posted by Michael Dürig <md...@apache.org>.
On 12.4.12 8:48, Angela Schreiber wrote:
>>> when looking at the current oak-api and the NodeStateEditor i
>>> don't see how we would currently be able to distinguish these
>>> different types.
>>
>> The current API should be able to cope with transient modifications and
>> non-transient modifications. The latter can be done by obtaining a new
>> connection just for those changes.
>
> that looks really wrong to me. the way i think of the oak-api
> is that i obtain the connection from oak-api upon Repository.login
> and it would be used for the communication for the lifespan of the
> JCR session obtained. retrieving another connection is definitely
> not what i am looking for as it would require separate
> authentication. that doesn't make sense to me.
See my reply to Jukka and my related commit of rev. 1325159.
>> Regarding the "special modifications" we still need to come up with a
>> way to handle those. They should IMO also be done through the
>> Connection, NodeEditor, etc. interfaces which might need to be tweaked
>> accordingly.
>
> as stated before i have the impression that this would need to
> be reflected on the API.
Yes, that's what I said. So let's come up with a way to do that.
>
>> The name reflects "transient" from JCR and should emphasis the fact that
>> instances of this class are - in contrast to NodeState - not Immutable.
>> However, we could rename this not MutableNodeState or something
>> different if you prefer.
>
> well... but in fact we would probably want to distinguish between
> transient operations that mark the associated JCR items modified/new
> until Session.save() is call, whereas all kind of workspace
> operations would never have that effect.... figure out the workspace
> operation fails during validation on oak-core. there should by
> no means a 'modified' flag being pending on the corresponding
> jcr items... we didn't that in the early stages of jackrabbit-core
> (as long as we had no real access control) and it didn't work.
Workspace operation should be doable now with my changes in rev.
1325159. I will try to implement copy and move to validate this.
TransientNodeState turned out to be a bad name for several reasons: 1.
it implies being a NodeState which it isn't, and 2. it implies a one to
one correspondences with transient modifications of JCR items which
seems a too restrictive assumption.
I think the next steps should be:
1. Validate my claim from above re. workspace operations
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.
3. In the process come up with better names.
Michael
>
> kind regards
> angela
>> Michael
>>
>>>
>>> kind regards
>>> angela
>>>
Re: Different types of 'item modification' on oak-jcr (and oak-api)
Posted by Angela Schreiber <an...@adobe.com>.
hi michael
> On 11.4.12 16:41, Angela Schreiber wrote:
>> hi
>>
>> thinking about how to implement the various JCR level operations
>> that are beyond regular item modification, i found that IMO
>> will face at least the following 4 types of writing that would
>> from a oak-api point of view may just look like item state
>> modifications:
>>
>> a) Regular JCR Item Modification [...]
>> b) Special JCR Item Modification [...]
>> c) Non-Transient JCR Item Modifications [...]
>> d) Non-Transient Special Item Modification [...]
>> when looking at the current oak-api and the NodeStateEditor i
>> don't see how we would currently be able to distinguish these
>> different types.
>
> The current API should be able to cope with transient modifications and
> non-transient modifications. The latter can be done by obtaining a new
> connection just for those changes.
that looks really wrong to me. the way i think of the oak-api
is that i obtain the connection from oak-api upon Repository.login
and it would be used for the communication for the lifespan of the
JCR session obtained. retrieving another connection is definitely
not what i am looking for as it would require separate
authentication. that doesn't make sense to me.
> Regarding the "special modifications" we still need to come up with a
> way to handle those. They should IMO also be done through the
> Connection, NodeEditor, etc. interfaces which might need to be tweaked
> accordingly.
as stated before i have the impression that this would need to
be reflected on the API.
> The name reflects "transient" from JCR and should emphasis the fact that
> instances of this class are - in contrast to NodeState - not Immutable.
> However, we could rename this not MutableNodeState or something
> different if you prefer.
well... but in fact we would probably want to distinguish between
transient operations that mark the associated JCR items modified/new
until Session.save() is call, whereas all kind of workspace
operations would never have that effect.... figure out the workspace
operation fails during validation on oak-core. there should by
no means a 'modified' flag being pending on the corresponding
jcr items... we didn't that in the early stages of jackrabbit-core
(as long as we had no real access control) and it didn't work.
kind regards
angela
> Michael
>
>>
>> kind regards
>> angela
>>
Re: Different types of 'item modification' on oak-jcr (and oak-api)
Posted by Michael Dürig <md...@apache.org>.
On 11.4.12 18:54, Jukka Zitting wrote:
> Hi,
>
> On Wed, Apr 11, 2012 at 6:30 PM, Michael Dürig<md...@apache.org> wrote:
>> The current API should be able to cope with transient modifications and
>> non-transient modifications. The latter can be done by obtaining a new
>> connection just for those changes.
>
> IMHO a separate connection shouldn't be needed for that, just a
> separate commit() against the same base state.
That would be a better solution I agree. Currently Connection.commit()
does an implicit refresh. We'd need to change that and do an explicit
refresh on the connection from the caller when needed.
>
>> The name reflects "transient" from JCR and should emphasis the fact that
>> instances of this class are - in contrast to NodeState - not Immutable.
>> However, we could rename this not MutableNodeState or something different if
>> you prefer.
>
> I'd rather not call such an interface *NodeState, as that suggests
> something that ISA NodeState, and thus a specialization, not a
> generalization of the supertype contract.
Agreed. But in lack of a better name...
Michael
>
> BR,
>
> Jukka Zitting
Re: Different types of 'item modification' on oak-jcr (and oak-api)
Posted by Angela Schreiber <an...@adobe.com>.
hi
> On Wed, Apr 11, 2012 at 6:30 PM, Michael Dürig<md...@apache.org> wrote:
>> The current API should be able to cope with transient modifications and
>> non-transient modifications. The latter can be done by obtaining a new
>> connection just for those changes.
>
> IMHO a separate connection shouldn't be needed for that, just a
> separate commit() against the same base state.
well... but my problem still would not be addressed:
first, in one case i wished to make changes on some sort of lower
level state in oak-jcr to be recorded as transient modifications
(the corresponding item to be marked new or modified) and in another
case i definitely would want to avoid that... the use case for those
lower-oak-jcr level transient modifications actually is that i dislike
the way we handle that in jackrabbit-core and at the same time i am
sure that we need to enforce the check for protected items
on oak-jcr. reason: if we want to represent such modifications as
regular item-changes on oak-api instead of having a separate API
defined for it, we won't be able to enforce the protected check on
oak-api any more... it would just be responsible for all the other
validation.
second, maybe i even had transient modifications pending and at the
same time would want to register a new node type but not committing
the transient modifications and i don't see a compelling reason
why that wouldn't be possible.
i was looking today how the Item.isNew() and isModified() flag is
set and found that this is missing altogether (though i thought
i had seen that before)... so, it looks to me that the current API
(or implementation) is missing some fundamental distinctions here.
>> The name reflects "transient" from JCR and should emphasis the fact that
>> instances of this class are - in contrast to NodeState - not Immutable.
>> However, we could rename this not MutableNodeState or something different if
>> you prefer.
>
> I'd rather not call such an interface *NodeState, as that suggests
> something that ISA NodeState, and thus a specialization, not a
> generalization of the supertype contract.
yes, and maybe this was exactly the place to introduce a distinction
between something that is transiently modified and some sort of
lower-level modified node 'state' that is just used to transport
changes to oak-api for validation.
regards
angela
> BR,
>
> Jukka Zitting
Re: Different types of 'item modification' on oak-jcr (and oak-api)
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Wed, Apr 11, 2012 at 6:30 PM, Michael Dürig <md...@apache.org> wrote:
> The current API should be able to cope with transient modifications and
> non-transient modifications. The latter can be done by obtaining a new
> connection just for those changes.
IMHO a separate connection shouldn't be needed for that, just a
separate commit() against the same base state.
> The name reflects "transient" from JCR and should emphasis the fact that
> instances of this class are - in contrast to NodeState - not Immutable.
> However, we could rename this not MutableNodeState or something different if
> you prefer.
I'd rather not call such an interface *NodeState, as that suggests
something that ISA NodeState, and thus a specialization, not a
generalization of the supertype contract.
BR,
Jukka Zitting
Re: Different types of 'item modification' on oak-jcr (and oak-api)
Posted by Michael Dürig <md...@apache.org>.
On 11.4.12 16:41, Angela Schreiber wrote:
> hi
>
> thinking about how to implement the various JCR level operations
> that are beyond regular item modification, i found that IMO
> will face at least the following 4 types of writing that would
> from a oak-api point of view may just look like item state
> modifications:
>
> a) Regular JCR Item Modification
> - transient modification on jcr items
> - example: Node.addNode, Item.remove, Property.setValue etc.
> - effect on oak-jcr:
> > Item or parent item is modified or new
> > Session has pending changes
> - effect on oak-api:
> > changes are not yet persisted and not visible on oak-api
> but only upon Session.save()
>
> b) Special JCR Item Modification:
> - transient modifications on jcr items through other API
> associated items may e.g. be protected
> - example: AccessControlManager.setPolicy, User.changePassword
> - effect on oak-jcr:
> > Item or parent item is modified or new
> > Session has pending changes
> - effect on oak-api:
> > changes are not yet persisted and not visible on oak-api
> but only upon Session.save()
>
> c) Non-Transient JCR Item Modifications:
> - workspace level jcr item modifications
> - example: Node.checkin, Workspace.clone, Workspace.move
> - effect on oak-jcr:
> > Item or parent item is neither modified nor new
> > Session doesn't have pending changes
> > changes are never visible as transient modification
> > no Session.save()
> - effect on oak-api:
> > either changes are directly passed to oak-api or there
> exists separate API methods on oak-api to cover these
> operations.
>
> d) Non-Transient Special Item Modification:
> - workspace or 'repository' level item modifications for
> special JCR functionality we may represent as content on
> lower levels
> - example: registered node types represented as jcr items under
> /jcr:system/jcr:nodetypes assuming that registration
> was mapped as simple item modification.
> - effect on oak-jcr:
> > Item or parent item is neither modified nor new
> > Session doesn't have pending changes
> > changes are never visible as transient modification
> > no Session.save()
> - effect on oak-api:
> > item modifications changes are directly passed to oak-api
> and validated, persisted accordingly
>
> when looking at the current oak-api and the NodeStateEditor i
> don't see how we would currently be able to distinguish these
> different types.
The current API should be able to cope with transient modifications and
non-transient modifications. The latter can be done by obtaining a new
connection just for those changes.
Regarding the "special modifications" we still need to come up with a
way to handle those. They should IMO also be done through the
Connection, NodeEditor, etc. interfaces which might need to be tweaked
accordingly.
>
> similarly, the TransientNodeState looks in this respect a bit
> odd to me as 'transient' and 'state' could be looked at as
> controversial concepts.
The name reflects "transient" from JCR and should emphasis the fact that
instances of this class are - in contrast to NodeState - not Immutable.
However, we could rename this not MutableNodeState or something
different if you prefer.
Michael
>
> kind regards
> angela
>