Re: [dna-dev] Generating Events For Child Nodes
On Nov 25, 2009, at 9:41 AM, Daniel Florian wrote:
The requirements for generating events for children of nodes that
have been added/removed/moved/copied seems to be different between JCR 1.0 to JCR 2.0. For
JCR 1.0 it seems these events are required. For JCR 2.0 it they are optional.
These 2 TCK observation tests are failing because of this:
NodeRemovedTest.testMultiNodesRemoved
WorkspaceOperationTest.testCopy
Here are the spec details:
1. JSR 170 1.0 (JCR 1.0 11 May 2005)
a. Section 8.3.7.1 Creating a new Node
... as well for each of the automatically created child nodes or properties (either
NODE_ADDED or PROPERTY_ADDED, as the case may be).
I think the connectors are already be doing this. No? But I read it as only a NODE_ADDED
is needed if a node is being created, and a PROPERTY_ADDED is only needed if a property is
created on an existing node (or maybe one that was created earlier). Thoughts?
b. Section 8.3.7.4 Removing a Child Node
... Additionally, an implementation should also generate a NODE_REMOVE or PROPERTY_REMOVE
(as appropriate) for each item in the removed subtree.
I think the connectors do not currently behave this way. The JPA connector has some code
to figure out the nodes being removed, but it's not yet using it. At least we
don't have to generate a PROPERTY_REMOVE for each property in the deleted subgraph!
Thoughts?
c. Section 8.3.7.6 Copying a Subtree
... Additionally, an implementation should generate appropriate events for each resulting
node and property addition in the copied subtree.
I don't think the connectors do this, but they probably should. I suspect just the
CopyBranchRequest is fired as an event. Again, my read is that we only need NODE_ADDED
for a new node and node a PROPERTY_ADDED for each property on the new node. Thoughts?
d Section 8.3.7.7 Moving a Subtree
... Additionally, an implementation should generate a NODE_REMOVE or PROPERTY_REMOVE (as
appropriate) for each node and property removed from its source path location and a
NODE_ADDED or PROPERTY_ADDED (as appropriate) for each node and property added at its
destination path location.
Crapola. This one sucks. If there's not a TCK test for this, we could choose to not
fire them and when we support JCR 2.0 we wouldn't have to either. Thoughts?
e. Section 8.3.7.8 Re-ordering a set of Child Nodes
... Additionally, an implementation should generate appropriate events reflecting the
“shifting over” of the node B and any nodes that come after it in the child node ordering.
Each such shifted node would also produce a NODE_REMOVED and NODE_ADDED event pair with
paths differing at most by a final index.
Hmm... I thought connectors were doing this, as it's pretty important to know that
nodes are being renamed, including when the SNS index changes.
2. JSR 283 FCS (JCR 2.0 10 Aug 2009)- Section 12.2 Scope of Event Reporting
The scope of event reporting is implementation-dependent. An implementation
should make a best-effort attempt to report all events, but may exclude events if
reporting them would be impractical given implementation or resource limitations.
For example, on an import, move or remove of a subgraph containing a large
number of items, an implementation may choose to report only events associated
with the root node of the affected graph and not those for every subitem in the
structure.
This is obviously where we want to be, but sounds like we can't start here.