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

Fri Oct 3 16:51:21 EDT 2008

    [ https://jira.jboss.org/jira/browse/DNA-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12432451#action_12432451 ] 

Randall Hauch commented on DNA-213:
-----------------------------------

Thought I'd summarize the major design elements of the commands/requests and how they're used by the connectors:  a connector client (e.g., the JCR implementation) creates a command for each request they want to have processed by a connector.  Multiple requests can be sent via a single call to the connector, so it's possible, for example, to create a graph of nodes all in one bulk call.

We can do some interesting things with the commands/requests.  First, we can batch them together (as I mentioned), or accumulated for delayed execution (e.g., when a transaction is committed).  Second, we could preprocess them, if we want to enforce certain orders or if we want to optimize a bunch of commands.  Third, they can be serialized, which will help with fault tolerance.  

A fourth benefit (and one of the more important) is that it gives us a lot of flexibility for future changes without needing to change the SPI.  For example, we could introduce new commands without requiring that connectors "understand" them (if the new commands could be executed by default using other commands).  This is where the CommandExecutor comes it ... it's an abstract class that defines methods for executing each type of command, and each connector "implements its behavior" by implementing an executor.  Some of the core "execute" methods are abstract, meaning the connector is required to implement them.  Other methods are optional.  For example, executing a command to delete a set of children of a node can be implemented in the abstract class by creating a "DeleteBranchCommand" for each child.  If a connector can implement this more efficiently, then it should probably override the default method.  However, it wouldn't have to, and as long it implemented the core execute methods, it would still work.

Now, we really don't want the commands to be exposed to clients, which is why we want to create a little API on top of the commands - this is what DNA-215 is all about.  Once we have this, the JCR implementation, sequencers, etc. could use this instead.  Under the covers, the API would be creating commands and sending them to the connector (when needed).

Okay, back to the issues.  We found out late in 0.2 that the commands didn't do everything we needed them to do, and if we're going to fix them, we need to do it quickly.  This is one of the reasons why we want 0.3 to be short - we want to get these changes out the door so that people can start writing connectors.  Thus, DNA-213 and DNA-215 are two of the biggest and most critical issues for 0.3.  (The other blocker issue is DNA-217, which has to do with cancellation.)

Right now, I want to get the core commands/requests done and done correctly.  We'll add others in the future - for example some for searching (e.g., via SQL, SPARQL, etc.).

> Review the graph SPI commands to add missing commands and better handle node identification (e.g., when getting children)
> -------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DNA-213
>                 URL: https://jira.jboss.org/jira/browse/DNA-213
>             Project: DNA
>          Issue Type: Task
>          Components: SPI
>    Affects Versions: 0.2
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Blocker
>             Fix For: 0.3
>
>         Attachments: dna-graph.patch
>
>
> The graph commands in the SPI were an initial attempt to identify the set of functionality that the connectors should support.  One problem with the current design is that it's not really feasible or possible to track with each child the identification properties for the child.  For example, when getting the children of a node, it's not mandatory (nor that clear) that identification properties be recorded for each child as well.  It's very important to provide a way for all nodes (including children) to be fully identified.
> Plus, we know that we're missing some very useful (if not required) commands, like the ability to get a node given some (or all) of its identification properties, and the ability to get a single property (with all values) for a node.
> Also, consider something that will make it easier to use these commands, such as a DSL.

-- 
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