[dna-dev] NetChangeObserver Questions

[Randall Hauch]

On Dec 1, 2009, at 10:01 AM, Daniel Florian wrote:

> Here are some questions concerning the NetChangeObserver class which I am modifying whilst implenting the observation feature:
> 
> 1. How do the CopyBranchRequest, CloneBranchRequest, RenameNodeRequest, and MoveBranchRequest create the node properties (and children)? I was expecting these types to be Iterable<Property> just like CreateNodeRequest so that I could generate the new property events. Don't I also need to add these property added events?

It may help to keep in mind the two different roles involved in using these requests.  The first role is that of the "requestor", whose job it is to create the request object with all the necessary input detail (via the constructors, since all input information is required at construction and is immutable).  The second role is that of the "processor" (e.g., typically a connector, though it can be any RequestProcessor), whose job it is to fulfill the request and add any output information (aka, "results") to the request.

For CreateNodeRequest, the requestor must supply the path (or parent location and child name) as well as any properties that are to be placed on the node immediately.  The processor verifies that the parent exists, creates the new node, and sets the actual location of the child node (which may contain IDs).

For CopyBranchRequest, the requestor only knows the location of the branch that is to be copied and the location where the copy is to be placed.  The processor then verifies the existing branch and the new location, then reads and copies the original branch, places the new copy at the desired location, and sets the "actual" locations for the original and new locations.  Because the requestor does not have to know anything about the content of the branch, this can be a cheap operation (at least from the requestor's perspective).  The more in-depth and resource-intensive approach would be to read the entire subgraph/branch and construct CreateNodeRequest for each node in the original branch - not only is there extra work, but there is potentially extra network traffic and the copy logic is not something the requestor has to do.  Plus, the processor might actually have an efficient way to perform the operation (e.g., the FileSystem connector might actually just do a file-system copy).

The CloneBranchRequest, RenameNodeRequest, and MoveBranchRequest are all similar to CopyBranchRequest.

So, on to the last sentence in your question.  The requestor doesn't really have any knowledge of or visibility into the side-effects of these requests (before or after processing).  What were the nodes that were created or changed or deleted as a result of these requests (other than the top-level nodes identified as part of the request)?  The only way to know about these side-effects is to observe the "processor" (in this case the connector), because all of the side effects should appear in the changes.  I say "should" because we need to change the connectors to produce these changes - I thought you were going to log an issue for this.

> 2. The docs for UpdateValuesRequest states that it can be used for a new property. If true, it would need the "isNewProperty()" method that was recently added to SetPropertyRequest and UpdatePropertiesRequest. Are the docs right?

Yes, the docs are right.  Looks like I forgot about this request when adding the 'isNewProperty()' behavior to the SetPropertyRequest and UpdatePropertiesRequest.  I will reopen and fix.

> 3. There is no way to get the Property object from UpdateValuesRequest. The Property type is needed in the call to NetChangeDetails.changedProperty(Property) and NetChangeDetails.addProperty(Property).

I'll probably add this when fixing re #2 above.

> 4. I added code to handle CreateWorkspaceRequest, DestroyWorkspaceRequest, and CloneWorkspaceRequest. Right now it just creates a NODE_ADDED event for the root node. Seems like I could remove all the code for these requests as no listeners could possibly exist for these new/deleted workspaces. Agree? If not, the CreateWorkspaceRequest and CloneWorkspaceRequest will need a way to say what properties were added to the root node. Same issue as #1 above. 

Technically a JCR session listener could observe the DestroyWorkspaceRequest (e.g., if another session destroyed the workspace), but that would also be followed by other exceptions and problems in the session itself.  You're right, though, that CreateWorkspaceRequest and CloneWorkspaceRequest would never be observable to a JCR session listener.  From JCR's perspective, there's no point in having the code.  However, from the DNA graph layer, it is possible to see all these events (since the graph layer has no notion of session), so I think it'd be nice to have these available in the NetChangeObserver framework.

Best regards,

Randall