You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by "Stephen Allen (JIRA)" <ji...@apache.org> on 2011/09/14 21:28:09 UTC
[jira] [Created] (JENA-116) DatasetGraphMap.getGraph() should call
addGraph() instead of adding directly to graph collection
DatasetGraphMap.getGraph() should call addGraph() instead of adding directly to graph collection
------------------------------------------------------------------------------------------------
Key: JENA-116
URL: https://issues.apache.org/jira/browse/JENA-116
Project: Jena
Issue Type: Bug
Components: ARQ
Reporter: Stephen Allen
Priority: Minor
The DatasetGraphMap class is useful for implementing a quad store as a collection of triplestores, but when you attempt to retrieve a graph that does not exist, a new one is created but bypasses the addGraph() method.
Parliament needs to register all new graphs in an internal table (so that it knows which directory and files on disk correspond to each graph). It does this by overriding the addGraph() method.
I've attached a patch that fixes this issue and also removes the "final" modifier on the getGraph() method (not strictly necessary for our use case, but it seemed out of place since no other methods are final, and I can imagine implementations that may want to override that method).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JENA-116) DatasetGraphMap.getGraph() should call
addGraph() instead of adding directly to graph collection
Posted by "Stephen Allen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JENA-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stephen Allen updated JENA-116:
-------------------------------
Attachment: JENA-116-r1170776.patch
> DatasetGraphMap.getGraph() should call addGraph() instead of adding directly to graph collection
> ------------------------------------------------------------------------------------------------
>
> Key: JENA-116
> URL: https://issues.apache.org/jira/browse/JENA-116
> Project: Jena
> Issue Type: Bug
> Components: ARQ
> Reporter: Stephen Allen
> Priority: Minor
> Attachments: JENA-116-r1170776.patch
>
>
> The DatasetGraphMap class is useful for implementing a quad store as a collection of triplestores, but when you attempt to retrieve a graph that does not exist, a new one is created but bypasses the addGraph() method.
> Parliament needs to register all new graphs in an internal table (so that it knows which directory and files on disk correspond to each graph). It does this by overriding the addGraph() method.
> I've attached a patch that fixes this issue and also removes the "final" modifier on the getGraph() method (not strictly necessary for our use case, but it seemed out of place since no other methods are final, and I can imagine implementations that may want to override that method).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (JENA-116) DatasetGraphMap.getGraph() should call
addGraph() instead of adding directly to graph collection
Posted by "Andy Seaborne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JENA-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andy Seaborne closed JENA-116.
------------------------------
> DatasetGraphMap.getGraph() should call addGraph() instead of adding directly to graph collection
> ------------------------------------------------------------------------------------------------
>
> Key: JENA-116
> URL: https://issues.apache.org/jira/browse/JENA-116
> Project: Jena
> Issue Type: Bug
> Components: ARQ
> Reporter: Stephen Allen
> Assignee: Andy Seaborne
> Priority: Minor
> Attachments: JENA-116-r1170776.patch
>
>
> The DatasetGraphMap class is useful for implementing a quad store as a collection of triplestores, but when you attempt to retrieve a graph that does not exist, a new one is created but bypasses the addGraph() method.
> Parliament needs to register all new graphs in an internal table (so that it knows which directory and files on disk correspond to each graph). It does this by overriding the addGraph() method.
> I've attached a patch that fixes this issue and also removes the "final" modifier on the getGraph() method (not strictly necessary for our use case, but it seemed out of place since no other methods are final, and I can imagine implementations that may want to override that method).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (JENA-116) DatasetGraphMap.getGraph() should call
addGraph() instead of adding directly to graph collection
Posted by "Andy Seaborne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JENA-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andy Seaborne resolved JENA-116.
--------------------------------
Resolution: Fixed
Assignee: Andy Seaborne
Patch applied - thanks.
> DatasetGraphMap.getGraph() should call addGraph() instead of adding directly to graph collection
> ------------------------------------------------------------------------------------------------
>
> Key: JENA-116
> URL: https://issues.apache.org/jira/browse/JENA-116
> Project: Jena
> Issue Type: Bug
> Components: ARQ
> Reporter: Stephen Allen
> Assignee: Andy Seaborne
> Priority: Minor
> Attachments: JENA-116-r1170776.patch
>
>
> The DatasetGraphMap class is useful for implementing a quad store as a collection of triplestores, but when you attempt to retrieve a graph that does not exist, a new one is created but bypasses the addGraph() method.
> Parliament needs to register all new graphs in an internal table (so that it knows which directory and files on disk correspond to each graph). It does this by overriding the addGraph() method.
> I've attached a patch that fixes this issue and also removes the "final" modifier on the getGraph() method (not strictly necessary for our use case, but it seemed out of place since no other methods are final, and I can imagine implementations that may want to override that method).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira