10:38 a.m.
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