From jira-events at lists.jboss.org  Wed Dec  3 17:48:36 2008
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 3 Dec 2008 17:48:36 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-40) Persistant storage
 for information not stored in other repository sources
Message-ID: <19922250.1228344516444.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-40:
----------------------------------

Implemented most of the connector behavior (just CopyBranchRequest remains, with a number of minor tasks).  Delete now uses an efficient mechanism for finding subgraphs.  The searches are stores in the database (in a "temporary" area), but this makes computing the subgraph very efficient (one self-join on the children's table per LEVEL of subgraph, not per node) and helps to keep most of the information out of memory.  The same mechanism is used for ReadBranchRequest (and will be used for CopyBranchRequest).

A number of methods also use Hibernate bulk HQL statements, which should be faster.  (The subgraph query is just one way in which they're used.)

Note that the "mark and sweep" approach to deleting nodes was abandoned, because the JCR spec requires that repositories generate delete events for every node that is deleted, not just for the top node in the subgraph that was deleted.

> Persistant storage for information not stored in other repository sources
> -------------------------------------------------------------------------
>
>                 Key: DNA-40
>                 URL: https://jira.jboss.org/jira/browse/DNA-40
>             Project: DNA
>          Issue Type: Feature Request
>          Components: Connectors
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> Create a federation connector that is able to manage information in a relational database using a DNA-defined schema.  This would enable the persistant storage of information that isn't being managed by other connectors.
> Requirements include efficiently storing and accessing large numbers of nodes, large property values (e.g., Binary values), and large numbers of children on nodes.  

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

        


From jira-events at lists.jboss.org  Wed Dec  3 17:48:36 2008
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 3 Dec 2008 17:48:36 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-40) Create connector to
 store any content in a relational database
Message-ID: <32865963.1228344516481.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch updated DNA-40:
-----------------------------

    Summary: Create connector to store any content in a relational database  (was: Persistant storage for information not stored in other repository sources)


Renamed to better reflect the actual need and approach.

> Create connector to store any content in a relational database
> --------------------------------------------------------------
>
>                 Key: DNA-40
>                 URL: https://jira.jboss.org/jira/browse/DNA-40
>             Project: DNA
>          Issue Type: Feature Request
>          Components: Connectors
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> Create a federation connector that is able to manage information in a relational database using a DNA-defined schema.  This would enable the persistant storage of information that isn't being managed by other connectors.
> Requirements include efficiently storing and accessing large numbers of nodes, large property values (e.g., Binary values), and large numbers of children on nodes.  

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

        


From jira-events at lists.jboss.org  Thu Dec  4 16:37:36 2008
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 4 Dec 2008 16:37:36 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-34) Federate content
 stored on file system
Message-ID: <22548537.1228426656458.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-34:
----------------------------------

Created an initial implementation of a simple read-only connector that is able to expose multiple directories as content.  A few things still need to be completed, even for the read-only case, but those will be done shortly.  But it is a start.

> Federate content stored on file system
> --------------------------------------
>
>                 Key: DNA-34
>                 URL: https://jira.jboss.org/jira/browse/DNA-34
>             Project: DNA
>          Issue Type: Feature Request
>          Components: Connectors
>            Reporter: Randall Hauch
>            Assignee: Stefano Maestri
>             Fix For: 0.5
>
>
> Create a connector for the federation engine that contributes and exposes content stored on the file system (in one or more directories) into the federated repository.  This connector would dynamically create the "nt:file" and "nt:folder" nodes to mirror the contents of the file system.

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

        


From jira-events at lists.jboss.org  Thu Dec  4 17:39:46 2008
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 4 Dec 2008 17:39:46 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-34) Federate content stored
 on file system
Message-ID: <11570711.1228430386671.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch updated DNA-34:
-----------------------------

    Fix Version/s: 0.4
                       (was: 0.5)


Initial version (read-only) is nearly finished, so retargeting to 0.4.

> Federate content stored on file system
> --------------------------------------
>
>                 Key: DNA-34
>                 URL: https://jira.jboss.org/jira/browse/DNA-34
>             Project: DNA
>          Issue Type: Feature Request
>          Components: Connectors
>            Reporter: Randall Hauch
>            Assignee: Stefano Maestri
>             Fix For: 0.4
>
>
> Create a connector for the federation engine that contributes and exposes content stored on the file system (in one or more directories) into the federated repository.  This connector would dynamically create the "nt:file" and "nt:folder" nodes to mirror the contents of the file system.

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

        


From jira-events at lists.jboss.org  Thu Dec  4 17:43:36 2008
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 4 Dec 2008 17:43:36 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-260) Add factory method
 to create a Binary instance from a (local) File
In-Reply-To: <18063324.1227458436493.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21812820.1228430616424.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-260:
-----------------------------------

Would need to address serialization of the Binary object, if it holds onto the File object (since the File object is not serializable).

> Add factory method to create a Binary instance from a (local) File
> ------------------------------------------------------------------
>
>                 Key: DNA-260
>                 URL: https://jira.jboss.org/jira/browse/DNA-260
>             Project: DNA
>          Issue Type: Feature Request
>          Components: API, Graph
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Priority: Minor
>             Fix For: 0.4
>
>
> A client sometimes has a file and wants to represent the content of the file with a Binary value object.  Currently, the client would have to obtain an InputStream or a Reader to the file, and create the Binary value object with that.  Then, when somebody wants to read the binary value, they have to create another stream/reader.  Essentially, the content is streamed 1+n times, where n is the number of times the value is read.  This can be very expensive when the size of the file is large (or very large, as in gigabytes).
> By adding a factor method that takes a File object, the factory could optimize the behavior.  Rather than creating a stream/reader to put the content into the Binary value object, the factory could just create a Binary implementation that delegates to a File.  Then, the only time a stream/reader is created is when the client wants to read the value.  In other words, the content is streamed only n times.
> We don't yet have a BinaryFactory interface, and are currently using ValueFactory<Binary>.  Therefore, the first step is to create the BinaryFactory interface and use this in the ValueFactories interface.  (Most uses of the 'getBinaryFactory()' method would not need to change, since they're either just immediately calling 'create(...)' on the returned reference, or are using ValueFactory<Binary>, which would still work.

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

        


From jira-events at lists.jboss.org  Thu Dec  4 18:03:36 2008
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 4 Dec 2008 18:03:36 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Assigned: (DNA-34) Federate content
 stored on file system
Message-ID: <8589295.1228431816502.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch reassigned DNA-34:
--------------------------------

    Assignee: Randall Hauch  (was: Stefano Maestri)


> Federate content stored on file system
> --------------------------------------
>
>                 Key: DNA-34
>                 URL: https://jira.jboss.org/jira/browse/DNA-34
>             Project: DNA
>          Issue Type: Feature Request
>          Components: Connectors
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> Create a connector for the federation engine that contributes and exposes content stored on the file system (in one or more directories) into the federated repository.  This connector would dynamically create the "nt:file" and "nt:folder" nodes to mirror the contents of the file system.

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

        


From jira-events at lists.jboss.org  Thu Dec  4 18:05:36 2008
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 4 Dec 2008 18:05:36 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-34) Federate content
 stored on file system
Message-ID: <14946596.1228431936419.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-34:
----------------------------------

Added a few more pieces of the implementation.  Still need to address determining mime types, binary values (see DNA-260), and unit tests.

> Federate content stored on file system
> --------------------------------------
>
>                 Key: DNA-34
>                 URL: https://jira.jboss.org/jira/browse/DNA-34
>             Project: DNA
>          Issue Type: Feature Request
>          Components: Connectors
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> Create a connector for the federation engine that contributes and exposes content stored on the file system (in one or more directories) into the federated repository.  This connector would dynamically create the "nt:file" and "nt:folder" nodes to mirror the contents of the file system.

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

        


From jira-events at lists.jboss.org  Thu Dec  4 18:08:36 2008
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 4 Dec 2008 18:08:36 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-264) Connectors may need to
 determine the MIME type for content
Message-ID: <22148120.1228432116535.JavaMail.jira@cloud.prod.atl2.jboss.com>

Connectors may need to determine the MIME type for content
----------------------------------------------------------

                 Key: DNA-264
                 URL: https://jira.jboss.org/jira/browse/DNA-264
             Project: DNA
          Issue Type: Task
            Reporter: Randall Hauch
            Assignee: Randall Hauch


Some connectors may need to be able to determine the MIME type for content, and there's currently no way in the connector API to do that.  The 'dna-graph' project does have MimeTypeDetector interface, but that's meant as a lower-level interface for an implementation.  MimeType was designed to be the main entry point for general components, but that's currently in 'dna-repository' (and connectors don't currently require that).

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

        


From jira-events at lists.jboss.org  Fri Dec  5 11:05:36 2008
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 5 Dec 2008 11:05:36 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-262) JCR-Level 2: Support
 persistent namespace changes
In-Reply-To: <19418054.1227540456463.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25780495.1228493136467.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch updated DNA-262:
------------------------------

    Component/s: JCR


> JCR-Level 2: Support persistent namespace changes
> -------------------------------------------------
>
>                 Key: DNA-262
>                 URL: https://jira.jboss.org/jira/browse/DNA-262
>             Project: DNA
>          Issue Type: Feature Request
>          Components: JCR
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> JCR Level 2 requires support for persisting changes to namespaces in the repository.  We can already support that with all of our connectors, since they're all able to store the namespace URIs for the content.  In fact, none of them currently store or use the prefixes.
> However, one thing DNA still doesn't have is the ability to manage the namespace prefixes in the connectors.  This probably will entail having a NamespaceRegistry implementation that can use a connector to populate the namespace registry.  This is a little tricky, tho, since the NamespaceRegistry is part of the ExecutionContext, which is passed to the connector's "execute(ExecutionContext,Request)" method.  So, while it is ideal that these namespace management methods are just additional requests, the dependency graph may imply that the namespace management methods need to be added to the RepositoryConnector interface.

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

        


From jira-events at lists.jboss.org  Fri Dec  5 11:05:36 2008
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 5 Dec 2008 11:05:36 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-253) Add support in the
 JBoss Cache connector for JBoss Cache 3.0.
In-Reply-To: <27426591.1227146796418.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29819789.1228493136658.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch updated DNA-253:
------------------------------

    Component/s: Connectors


> Add support in the JBoss Cache connector for JBoss Cache 3.0. 
> --------------------------------------------------------------
>
>                 Key: DNA-253
>                 URL: https://jira.jboss.org/jira/browse/DNA-253
>             Project: DNA
>          Issue Type: Thirdparty Change
>          Components: Connectors
>            Reporter: Randall Hauch
>             Fix For: 0.4
>
>
> JBoss Cache 3.0.0.GA is available (as of Nov 19, 2008), so we should add support for using it in DNA's JBoss Cache connector.  The connector is currently using 2.2.1.GA.  3.0.0.GA is supposed to be API compatible with 2.2.1.GA, but there are some deprecated methods and a new configuration format.  Hopefully we're not using any deprecated methods, and the connector does almost no configuration (instead, it assumes that any cache that requires connfiguration will be placed inside JNDI, or the name of the configuration will be referenced by the JBossCacheSource.

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

        


From jira-events at lists.jboss.org  Fri Dec  5 11:07:36 2008
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 5 Dec 2008 11:07:36 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-39) Federate content from a
 JCR repository
Message-ID: <20516341.1228493256768.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch updated DNA-39:
-----------------------------

    Fix Version/s: 0.5
                       (was: 0.4)


Pushing beyond 0.4. Other issues keep taking higher priority.

> Federate content from a JCR repository
> --------------------------------------
>
>                 Key: DNA-39
>                 URL: https://jira.jboss.org/jira/browse/DNA-39
>             Project: DNA
>          Issue Type: Feature Request
>          Components: Connectors
>            Reporter: Randall Hauch
>             Fix For: 0.5
>
>
> Create a connector for the federation engine that contributes and exposes the content in a JCR repository into the federated repository.  Initial implementation could be read-only.

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

        


From jira-events at lists.jboss.org  Mon Dec  8 11:54:36 2008
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 8 Dec 2008 11:54:36 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-250) Creating a path from
 a parent path and a segment is not fast
In-Reply-To: <11083814.1226423496433.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21066977.1228755276550.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-250:
-----------------------------------

Added new specialized implementations of Path, including RootPath and ChildPath.  ChildPath is much more efficient when creating paths based upon an existing parent path.  Also cleaned up and corrected some Path documentation, and added unit tests.  Created a new utility class that implements List that appends (virtually) a single element to an already immutable list.  This is useful when having to create a List (e.g., of Path.Segment objects) based upon an existing List but with a single additional element.

> Creating a path from a parent path and a segment is not fast
> ------------------------------------------------------------
>
>                 Key: DNA-250
>                 URL: https://jira.jboss.org/jira/browse/DNA-250
>             Project: DNA
>          Issue Type: Bug
>          Components: Graph
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Critical
>             Fix For: 0.4
>
>
> Currently, we only have one implementation of Path, and each instance contains a list of the Path.Segment instances in the path.  Although the actual Path.Segment instances are shared when creating a path using a parent path, the actual list is not shared.  And this means new allocation for each Path.  This could be more efficient, especially since creating a path from a parent path and a name is perhaps one of the most frequently used methods.
> We probably need an implementation of Path that contains a name plus a reference to a parent.  This would have a smaller memory footprint as well as be faster to create.

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

        


From jira-events at lists.jboss.org  Mon Dec  8 13:39:36 2008
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 8 Dec 2008 13:39:36 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-36) Federate content from
	SVN
Message-ID: <16773562.1228761576929.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-36:
----------------------------------

Changed the way the local repository is created to better match how Hudson works (hopefully).  Also changed to use the FileUtil.deletemethod, and moved the copy functionality into FileUtil.  Finally, changed the asserts in the SVNRepositoryConnection constructor to be arg checks; this is more testable (as unit tests should not be expecting AssertionError, as then it is not possible to run the unit tests against the code with asserts removed.

> Federate content from SVN
> -------------------------
>
>                 Key: DNA-36
>                 URL: https://jira.jboss.org/jira/browse/DNA-36
>             Project: DNA
>          Issue Type: Feature Request
>          Components: Connectors
>    Affects Versions: 0.4
>            Reporter: Randall Hauch
>            Assignee: Serge Emmanuel Pagop
>            Priority: Minor
>             Fix For: 0.4
>
>
> Create a connector for the federation engine that contributes and exposes content stored in a source control management (SCM) system into the federated repository.  This would enable integration of files managed by SVN (or CVS, etc.) to be accessible via JCR.

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

        


From jira-events at lists.jboss.org  Tue Dec  9 21:28:36 2008
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 9 Dec 2008 21:28:36 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-250) Creating a path from
 a parent path and a segment is not fast
In-Reply-To: <11083814.1226423496433.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10077844.1228876116426.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-250:
-----------------------------------

Added an optimized check during the isAtOrBelow and isAtOrAbove methods, and removed the caching of the string form of the path (which was cached based upon the first call to any of the getString methods, regardless of the NamespaceRegistry instance used, meaning the cached string might have used no namespace registry and was returned from a getString(...) that took a namespace registry.  Also, the extra overhead of the cached string was not worth the memory.

> Creating a path from a parent path and a segment is not fast
> ------------------------------------------------------------
>
>                 Key: DNA-250
>                 URL: https://jira.jboss.org/jira/browse/DNA-250
>             Project: DNA
>          Issue Type: Bug
>          Components: Graph
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Critical
>             Fix For: 0.4
>
>
> Currently, we only have one implementation of Path, and each instance contains a list of the Path.Segment instances in the path.  Although the actual Path.Segment instances are shared when creating a path using a parent path, the actual list is not shared.  And this means new allocation for each Path.  This could be more efficient, especially since creating a path from a parent path and a name is perhaps one of the most frequently used methods.
> We probably need an implementation of Path that contains a name plus a reference to a parent.  This would have a smaller memory footprint as well as be faster to create.

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

        


From jira-events at lists.jboss.org  Fri Dec 12 17:39:36 2008
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 12 Dec 2008 17:39:36 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-265) Improve the Graph
 API's methods for returning blocks of children
Message-ID: <33145400.1229121576696.JavaMail.jira@cloud.prod.atl2.jboss.com>

Improve the Graph API's methods for returning blocks of children
----------------------------------------------------------------

                 Key: DNA-265
                 URL: https://jira.jboss.org/jira/browse/DNA-265
             Project: DNA
          Issue Type: Feature Request
          Components: API, Graph
    Affects Versions: 0.3
            Reporter: Randall Hauch
            Assignee: Randall Hauch
            Priority: Minor
             Fix For: 0.4


The Graph API has several methods for getting a subset (or "block") of children by specifying the parent, starting index, and child.  This is useful when a graph client is paging through the children.  However, the Graph API methods to do this are less than ideal and don't make for readable code.  Plus, there is a use case when the client doesn't want to specify the index, but rather they want to specify the last child that they read.  This may be more appealing to some clients for cases when the children are being modified, and the indexes change in between calls to read blocks.

The Graph API should be changed to make getting children more closely aligned with the method to get all children, so that developers can decide after they add the "getChildren()." call, letting the IDE show the different options.  Also, the API should supporting getting n children after a previously-retrieved sibling.

Here are some examples of what the new API should look like.  This line:

    graph.getChildren().of(parent);

gets all children of the 'parent' node (where 'parent' can be a string path, Path, Location, UUID, or identification Property objects).  This line:

    graph.getChildren().inBlockOf(10).startingAt(50).under(parent);

gets up to 10 children under a parent node, starting at the 51st child (remember, indexes are 0-based).  And this line:

    graph.getChildren().inBlockOf(10).startingAfter(sibling);

gets up to 10 children that immediately follow the 'sibling' node.  Here, 'sibling' can be a string path, Path,  Location, UUID, or identification Property objects, but will often be the actual Location returned from a previous call.

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

        


From jira-events at lists.jboss.org  Fri Dec 12 18:00:36 2008
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 12 Dec 2008 18:00:36 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-265) Improve the Graph
 API's methods for returning blocks of children
In-Reply-To: <33145400.1229121576696.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29683551.1229122836425.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch resolved DNA-265.
-------------------------------

    Resolution: Done


Changed the Graph API to improve the methods of getting blocks of children, including adding a new technique for getting the 'n' children that follow a previously-returned sibling.  This did change the API, but these were methods that were not used except in test cases.

> Improve the Graph API's methods for returning blocks of children
> ----------------------------------------------------------------
>
>                 Key: DNA-265
>                 URL: https://jira.jboss.org/jira/browse/DNA-265
>             Project: DNA
>          Issue Type: Feature Request
>          Components: API, Graph
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Minor
>             Fix For: 0.4
>
>
> The Graph API has several methods for getting a subset (or "block") of children by specifying the parent, starting index, and child.  This is useful when a graph client is paging through the children.  However, the Graph API methods to do this are less than ideal and don't make for readable code.  Plus, there is a use case when the client doesn't want to specify the index, but rather they want to specify the last child that they read.  This may be more appealing to some clients for cases when the children are being modified, and the indexes change in between calls to read blocks.
> The Graph API should be changed to make getting children more closely aligned with the method to get all children, so that developers can decide after they add the "getChildren()." call, letting the IDE show the different options.  Also, the API should supporting getting n children after a previously-retrieved sibling.
> Here are some examples of what the new API should look like.  This line:
>     graph.getChildren().of(parent);
> gets all children of the 'parent' node (where 'parent' can be a string path, Path, Location, UUID, or identification Property objects).  This line:
>     graph.getChildren().inBlockOf(10).startingAt(50).under(parent);
> gets up to 10 children under a parent node, starting at the 51st child (remember, indexes are 0-based).  And this line:
>     graph.getChildren().inBlockOf(10).startingAfter(sibling);
> gets up to 10 children that immediately follow the 'sibling' node.  Here, 'sibling' can be a string path, Path,  Location, UUID, or identification Property objects, but will often be the actual Location returned from a previous call.

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

        


From jira-events at lists.jboss.org  Fri Dec 12 18:02:36 2008
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 12 Dec 2008 18:02:36 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-40) Create connector to
 store any content in a relational database
Message-ID: <12566011.1229122956469.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-40:
----------------------------------

Changed the Graph API to improve the methods of getting blocks of children, including adding a new technique for getting the 'n' children that follow a previously-returned sibling.  This did change the API, but these were methods that were not used except in test cases.

Also implemented in the JPA Store connector the process methods for ReadBlockOfChildrenRequest and ReadNextBlockOfChildrenRequest, utilizing efficient database operations for these methods to efficiently find and return the block of children.

> Create connector to store any content in a relational database
> --------------------------------------------------------------
>
>                 Key: DNA-40
>                 URL: https://jira.jboss.org/jira/browse/DNA-40
>             Project: DNA
>          Issue Type: Feature Request
>          Components: Connectors
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> Create a federation connector that is able to manage information in a relational database using a DNA-defined schema.  This would enable the persistant storage of information that isn't being managed by other connectors.
> Requirements include efficiently storing and accessing large numbers of nodes, large property values (e.g., Binary values), and large numbers of children on nodes.  

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

        


From jira-events at lists.jboss.org  Fri Dec 12 18:02:36 2008
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 12 Dec 2008 18:02:36 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-250) Creating a path from
 a parent path and a segment is not fast
In-Reply-To: <11083814.1226423496433.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11327443.1229122956528.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch resolved DNA-250.
-------------------------------

    Resolution: Done


These changes do improve performance and reduce the memory and time required to work with Paths.  Marking as closed.

> Creating a path from a parent path and a segment is not fast
> ------------------------------------------------------------
>
>                 Key: DNA-250
>                 URL: https://jira.jboss.org/jira/browse/DNA-250
>             Project: DNA
>          Issue Type: Bug
>          Components: Graph
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Critical
>             Fix For: 0.4
>
>
> Currently, we only have one implementation of Path, and each instance contains a list of the Path.Segment instances in the path.  Although the actual Path.Segment instances are shared when creating a path using a parent path, the actual list is not shared.  And this means new allocation for each Path.  This could be more efficient, especially since creating a path from a parent path and a name is perhaps one of the most frequently used methods.
> We probably need an implementation of Path that contains a name plus a reference to a parent.  This would have a smaller memory footprint as well as be faster to create.

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

        


From jira-events at lists.jboss.org  Fri Dec 12 18:04:36 2008
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 12 Dec 2008 18:04:36 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Assigned: (DNA-260) Add factory method to
 create a Binary instance from a (local) File
In-Reply-To: <18063324.1227458436493.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29433603.1229123076422.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch reassigned DNA-260:
---------------------------------

    Assignee: Randall Hauch


> Add factory method to create a Binary instance from a (local) File
> ------------------------------------------------------------------
>
>                 Key: DNA-260
>                 URL: https://jira.jboss.org/jira/browse/DNA-260
>             Project: DNA
>          Issue Type: Feature Request
>          Components: API, Graph
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Minor
>             Fix For: 0.4
>
>
> A client sometimes has a file and wants to represent the content of the file with a Binary value object.  Currently, the client would have to obtain an InputStream or a Reader to the file, and create the Binary value object with that.  Then, when somebody wants to read the binary value, they have to create another stream/reader.  Essentially, the content is streamed 1+n times, where n is the number of times the value is read.  This can be very expensive when the size of the file is large (or very large, as in gigabytes).
> By adding a factor method that takes a File object, the factory could optimize the behavior.  Rather than creating a stream/reader to put the content into the Binary value object, the factory could just create a Binary implementation that delegates to a File.  Then, the only time a stream/reader is created is when the client wants to read the value.  In other words, the content is streamed only n times.
> We don't yet have a BinaryFactory interface, and are currently using ValueFactory<Binary>.  Therefore, the first step is to create the BinaryFactory interface and use this in the ValueFactories interface.  (Most uses of the 'getBinaryFactory()' method would not need to change, since they're either just immediately calling 'create(...)' on the returned reference, or are using ValueFactory<Binary>, which would still work.

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

        


From jira-events at lists.jboss.org  Tue Dec 16 11:19:54 2008
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 16 Dec 2008 11:19:54 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-40) Create connector to
 store any content in a relational database
Message-ID: <19371068.1229444394380.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-40:
----------------------------------

Added to the JPA connector support for referential integrity (which is optional).  References that are values in properties are now tracked in the database, where each reference record maps the UUID of the node containing the reference to the UUID of the node being referenced.  Note that this table does not maintain which property contains the reference, which is not required to manage dependencies.

Finally, these references are checked upon closing the BasicRequestProcessor to catch any operations that remove any nodes that are still being referenced by other nodes.

> Create connector to store any content in a relational database
> --------------------------------------------------------------
>
>                 Key: DNA-40
>                 URL: https://jira.jboss.org/jira/browse/DNA-40
>             Project: DNA
>          Issue Type: Feature Request
>          Components: Connectors
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> Create a federation connector that is able to manage information in a relational database using a DNA-defined schema.  This would enable the persistant storage of information that isn't being managed by other connectors.
> Requirements include efficiently storing and accessing large numbers of nodes, large property values (e.g., Binary values), and large numbers of children on nodes.  

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

        


From jira-events at lists.jboss.org  Wed Dec 17 10:56:54 2008
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 17 Dec 2008 10:56:54 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-40) Create connector to
 store any content in a relational database
Message-ID: <15843188.1229529414550.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-40:
----------------------------------

Completed the connector's method to process branch copy requests, and added more unit tests.  Fixed a bug in the CopyBranchRequest class - when setting the actual locations, the request was incorrectly checking that the actual location matched that of the "into" location (which is the parent of the new copy), rather than the actual location of the new copy.

> Create connector to store any content in a relational database
> --------------------------------------------------------------
>
>                 Key: DNA-40
>                 URL: https://jira.jboss.org/jira/browse/DNA-40
>             Project: DNA
>          Issue Type: Feature Request
>          Components: Connectors
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> Create a federation connector that is able to manage information in a relational database using a DNA-defined schema.  This would enable the persistant storage of information that isn't being managed by other connectors.
> Requirements include efficiently storing and accessing large numbers of nodes, large property values (e.g., Binary values), and large numbers of children on nodes.  

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

        


From jira-events at lists.jboss.org  Wed Dec 17 10:56:54 2008
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 17 Dec 2008 10:56:54 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Work stopped: (DNA-40) Create connector
 to store any content in a relational database
Message-ID: <11876091.1229529414675.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on DNA-40 stopped by Randall Hauch.

> Create connector to store any content in a relational database
> --------------------------------------------------------------
>
>                 Key: DNA-40
>                 URL: https://jira.jboss.org/jira/browse/DNA-40
>             Project: DNA
>          Issue Type: Feature Request
>          Components: Connectors
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> Create a federation connector that is able to manage information in a relational database using a DNA-defined schema.  This would enable the persistant storage of information that isn't being managed by other connectors.
> Requirements include efficiently storing and accessing large numbers of nodes, large property values (e.g., Binary values), and large numbers of children on nodes.  

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

        


From jira-events at lists.jboss.org  Wed Dec 17 10:56:55 2008
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 17 Dec 2008 10:56:55 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-40) Create connector to
 store any content in a relational database
Message-ID: <19288339.1229529415937.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch resolved DNA-40.
------------------------------

    Resolution: Done


At this point, the connector may be complete.  Will mark as closed, but may need to reopen if there are any additional issues.

> Create connector to store any content in a relational database
> --------------------------------------------------------------
>
>                 Key: DNA-40
>                 URL: https://jira.jboss.org/jira/browse/DNA-40
>             Project: DNA
>          Issue Type: Feature Request
>          Components: Connectors
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> Create a federation connector that is able to manage information in a relational database using a DNA-defined schema.  This would enable the persistant storage of information that isn't being managed by other connectors.
> Requirements include efficiently storing and accessing large numbers of nodes, large property values (e.g., Binary values), and large numbers of children on nodes.  

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

        


From jira-events at lists.jboss.org  Thu Dec 18 17:39:54 2008
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 18 Dec 2008 17:39:54 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-266) Improve usability of
 graph API with additional methods
Message-ID: <5000412.1229639994257.JavaMail.jira@cloud.prod.atl2.jboss.com>

Improve usability of graph API with additional methods
------------------------------------------------------

                 Key: DNA-266
                 URL: https://jira.jboss.org/jira/browse/DNA-266
             Project: DNA
          Issue Type: Feature Request
          Components: API, Graph
    Affects Versions: 0.3
            Reporter: Randall Hauch
            Assignee: Randall Hauch
            Priority: Minor
             Fix For: 0.4


Provide an easy way to set references to nodes as property values.  Currently, one has to get the node, obtain a reference value factory, create the reference, then set the property using that value.  It's pretty impossible to make a single chained call that does all this.

Also, provide additional flexibility when setting properties.  Currently, the only way to set a property is to do the following:
        graph.set("propName").to("value").on("/node1");
but it would also be nice to reverse the "on" and "to" methods, such as:
        graph.set("propName").on("/node1").to("value");


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

        


From jira-events at lists.jboss.org  Thu Dec 18 17:46:54 2008
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 18 Dec 2008 17:46:54 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-266) Improve usability of
 graph API with additional methods
In-Reply-To: <5000412.1229639994257.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24079992.1229640414422.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-266:
-----------------------------------

Added an easy way to set references to nodes as property values.  Any Node or Location passed as a property value will automatically be converted to a Reference property value pointing to the UUID of the Node (or Location).  Also added additional "to" methods (for setting property values) that take a Node and Location, making it more obvious what values are allowed.

Also changed the SetValuesTo interface so that it's possible to specify the "on" before the values.  For example:
        graph.set("propName").to("value").on("/node1");
        graph.set("propName").on("/node1").to("value");
The first example was what was original required, but the bottom one also works now.  Notice that the 3rd method called in each of these ("on" in the first, "to" in the second example) returns an interface that completes the set operation.  In other words, the following results in a compile error:
        graph.set("propName").to("value").on("/node1").to("value2");
This is great, since it is the desired behavior.

> Improve usability of graph API with additional methods
> ------------------------------------------------------
>
>                 Key: DNA-266
>                 URL: https://jira.jboss.org/jira/browse/DNA-266
>             Project: DNA
>          Issue Type: Feature Request
>          Components: API, Graph
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Minor
>             Fix For: 0.4
>
>
> Provide an easy way to set references to nodes as property values.  Currently, one has to get the node, obtain a reference value factory, create the reference, then set the property using that value.  It's pretty impossible to make a single chained call that does all this.
> Also, provide additional flexibility when setting properties.  Currently, the only way to set a property is to do the following:
>         graph.set("propName").to("value").on("/node1");
> but it would also be nice to reverse the "on" and "to" methods, such as:
>         graph.set("propName").on("/node1").to("value");

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

        


From jira-events at lists.jboss.org  Thu Dec 18 17:52:54 2008
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 18 Dec 2008 17:52:54 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-40) Create connector to
 store any content in a relational database
Message-ID: <22943850.1229640774400.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-40:
----------------------------------

Per JSR-283 section 5.1.7, corrected this connector's copy behavior for how "internal" references (from nodes within the subgraph to nodes also within the subgraph) are remapped in the copy, so that the copy's references are also internal to the copy.  Also verified that "outward" references (from nodes within the subgraph to nodes outside of the subgraph) are copied correctly, and that "inward" references (from nodes outside of the original subgraph to nodes in the original subgraph) are not affected by the copy operation (since the original subgraph is not modified).

Note that JSR-170 does not define the semantics of how references are handled in a copy operation.

> Create connector to store any content in a relational database
> --------------------------------------------------------------
>
>                 Key: DNA-40
>                 URL: https://jira.jboss.org/jira/browse/DNA-40
>             Project: DNA
>          Issue Type: Feature Request
>          Components: Connectors
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> Create a federation connector that is able to manage information in a relational database using a DNA-defined schema.  This would enable the persistant storage of information that isn't being managed by other connectors.
> Requirements include efficiently storing and accessing large numbers of nodes, large property values (e.g., Binary values), and large numbers of children on nodes.  

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

        


From jira-events at lists.jboss.org  Fri Dec 19 14:51:04 2008
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 19 Dec 2008 14:51:04 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-266) Improve usability of
 graph API with additional methods
In-Reply-To: <5000412.1229639994257.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4245991.1229716264739.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-266:
-----------------------------------

Added additional methods for setting the values of properties, overloading with the different types allowed for property values (e.g., boolean, int, Path, Name, etc.).  This resulted in quite a bit more code (that is all pretty straightforward), but this detriment is outweighed by the API being more useful and clear.

> Improve usability of graph API with additional methods
> ------------------------------------------------------
>
>                 Key: DNA-266
>                 URL: https://jira.jboss.org/jira/browse/DNA-266
>             Project: DNA
>          Issue Type: Feature Request
>          Components: API, Graph
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Minor
>             Fix For: 0.4
>
>
> Provide an easy way to set references to nodes as property values.  Currently, one has to get the node, obtain a reference value factory, create the reference, then set the property using that value.  It's pretty impossible to make a single chained call that does all this.
> Also, provide additional flexibility when setting properties.  Currently, the only way to set a property is to do the following:
>         graph.set("propName").to("value").on("/node1");
> but it would also be nice to reverse the "on" and "to" methods, such as:
>         graph.set("propName").on("/node1").to("value");

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

        


From jira-events at lists.jboss.org  Fri Dec 19 14:51:04 2008
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 19 Dec 2008 14:51:04 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-266) Improve usability of
 graph API with additional methods
In-Reply-To: <5000412.1229639994257.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29885216.1229716264787.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch resolved DNA-266.
-------------------------------

    Resolution: Done


Marking as resolved.  This can be reopened if there are any additions.

> Improve usability of graph API with additional methods
> ------------------------------------------------------
>
>                 Key: DNA-266
>                 URL: https://jira.jboss.org/jira/browse/DNA-266
>             Project: DNA
>          Issue Type: Feature Request
>          Components: API, Graph
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Minor
>             Fix For: 0.4
>
>
> Provide an easy way to set references to nodes as property values.  Currently, one has to get the node, obtain a reference value factory, create the reference, then set the property using that value.  It's pretty impossible to make a single chained call that does all this.
> Also, provide additional flexibility when setting properties.  Currently, the only way to set a property is to do the following:
>         graph.set("propName").to("value").on("/node1");
> but it would also be nice to reverse the "on" and "to" methods, such as:
>         graph.set("propName").on("/node1").to("value");

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

        


