[dna-issues] [JBoss JIRA] Updated: (DNA-213) Review the graph SPI commands to add missing commands and better handle node identification (e.g., when getting children)

[ https://jira.jboss.org/jira/browse/DNA-213?page=com.atlassian.jira.plugin... ] Randall Hauch updated DNA-213: ------------------------------ Attachment: dna-graph.patch A couple of problems were addressed by this prototype (represented as a new package in "dna-graph"; see the attached patch file). First, inheritance between commands was a problem. Second, the current commands rely upon a path to define the location of a node, and this does not allow connectors to work with UUIDs or with other identification properties. Third, the naming convention of the commands was not obvious. I created a new family of commands that hopefully address these issues. Rather than use the same package, I created them in a new package (I think this will easy migration of the code during this change). Also, these use the term "request" rather than "command", since it's important to understand that these requests (such as ReadNodeRequest) are really requests to perform operations. Hopefully this helps a little with the naming convention problems. To address the remaining naming convention issues, the requests use a different convention for the members that are defined as part of the request vs the result of the request. Thus, the information that is part of the actual request (e.g., "at()" for a location, or "properties()" for the properties that are to be updated on a node) are obtained with methods that don't begin with a "get" prefix. Any method that does begin with "get" then represents a part of the information the request is returning. (There are often correlated "set" methods that the connectors use to set these results on a request.) Although all of the requests extend the abstract "Request" class, there are no other inheritance. This allows any logic relying upon instanceof to be much more clear, and this is an important part of the execution abstract classes. For example, the RequestProcessor (formerly the CommandExecutor) can have a methods to process each type of request class. This is what connector implementors will subclass and override the methods they want to implement. Having too much inheritance makes this overriding messy and complicated, so this design avoids that altogether. Because inheritance is not used, there are some request classes that have duplicate (or very similar code). Composition could have reduced the amount of duplication, but it would have increased the size of the instances (by adding a reference for each composed object). That adds up over time. The current design is much less complex, too (the duplicated code is mostly just getters). Plus, the current design also means that the different request classes can evolve independently. Note that this patch file does not contain a RequestProcessor. Comments are welcome and encouraged. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira