[dna-dev] Generating Events For Child Nodes

[Randall Hauch]

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.