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
