[JBoss JIRA] Created: (DNA-213) Review the graph SPI commands to better handle node identification (e.g., when getting children)
4:50 p.m.
Review the graph SPI commands to 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
Fix For: 0.2
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.
--
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
4:54 p.m.
New subject: [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:
------------------------------
Summary: Review the graph SPI commands to add missing commands and better handle
node identification (e.g., when getting children) (was: Review the graph SPI commands to
better handle node identification (e.g., when getting children))
Description:
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.
was: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.
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
Fix For: 0.2
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
7:56 p.m.
New subject: [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:
------------------------------
Fix Version/s: 0.3
(was: 0.2)
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
Fix For: 0.3
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
10:24 p.m.
New subject: [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.
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
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
10:51 p.m.
New subject: [JBoss JIRA] Commented: (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 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
10:25 p.m.
New subject: [JBoss JIRA] Commented: (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 commented on DNA-213:
-----------------------------------
Minor changes to the code that was in the patch, and it's now committed to SVN. Added
a RequestProcessor abstract class.
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
8:47 p.m.
New subject: [JBoss JIRA] Resolved: (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 resolved DNA-213.
-------------------------------
Resolution: Done
Finished the conversion from the old GraphCommand classes to the newer Request classes.
This involved a very large number of changes, some of which changed from using commands to
using the new Graph API. The new Request classes do a much better job of recording
identification properties of the nodes added as results to the requests.
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
5687
days inactive
5744
days old
6 comments
1 participants
participants (1)
-
Randall Hauch (JIRA)