[jira] [Updated] (JENA-174) Linearization optimization does not account for SERVICE correctly.

[Andy Seaborne (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne updated JENA-174:
---
Description: 
{noformat}
SELECT ?p ?o WHERE
{
{ BIND( AS ?service)}
UNION
{ BIND( AS ?service)}
SERVICE ?service
{ ?p ?o. }
}
{noformat}
==>
{noformat}
(project (?p ?o)
  (join
(union
  (extend ((?service ))
(table unit))
  (extend ((?service ))
(table unit)))
(service ?service
  (bgp (triple  ?p ?o)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(project (?p ?o)
  (sequence
(union
  (extend ((?service ))
(table unit))
  (extend ((?service ))
(table unit)))
(service ?service
  (bgp (triple  ?p ?o)
{noformat}

  was:
SELECT ?p ?o WHERE
{
{ BIND( AS ?service)}
UNION
{ BIND( AS ?service)}
SERVICE ?service
{ ?p ?o. }
}

==>
(project (?p ?o)
  (join
(union
  (extend ((?service ))
(table unit))
  (extend ((?service ))
(table unit)))
(service ?service
  (bgp (triple  ?p ?o)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(project (?p ?o)
  (sequence
(union
  (extend ((?service ))
(table unit))
  (extend ((?service ))
(table unit)))
(service ?service
  (bgp (triple  ?p ?o)



> Linearization optimization does not account for SERVICE correctly.
> --
>
> Key: JENA-174
> URL: https://issues.apache.org/jira/browse/JENA-174
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ, Optimizer
>Reporter: Andy Seaborne
>Priority: Minor
>
> {noformat}
> SELECT ?p ?o WHERE
> {
> { BIND( AS ?service)}
> UNION
> { BIND( AS ?service)}
> SERVICE ?service
> { ?p ?o. }
> }
> {noformat}
> ==>
> {noformat}
> (project (?p ?o)
>   (join
> (union
>   (extend ((?service ))
> (table unit))
>   (extend ((?service ))
> (table unit)))
> (service ?service
>   (bgp (triple  ?p ?o)
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> (project (?p ?o)
>   (sequence
> (union
>   (extend ((?service ))
> (table unit))
>   (extend ((?service ))
> (table unit)))
> (service ?service
>   (bgp (triple  ?p ?o)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (JENA-64) Failed read of imported ontology leaves a memory in the ModelMaker

[Andy Seaborne (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne closed JENA-64.
-

> Failed read of imported ontology leaves a memory in the ModelMaker
> --
>
> Key: JENA-64
> URL: https://issues.apache.org/jira/browse/JENA-64
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Ontology API
>Reporter: Ian Dickinson
>Assignee: Ian Dickinson
>Priority: Major
>
> If an OntModel tries to create sub-models for imports, and the attempt to 
> read an import fails, an empty model is left associated with the source URL 
> in the memory retained by SimpleGraphMaker. Subsequent attempts to read the 
> import URI, e.g. with a FileManager redirect in place to avoid the network 
> issue, return only the empty model from the failed read and do not read the 
> updated source.
> Failed model reads should not leave a memory in the graph maker. Possibly, 
> graph maker should not have a memory at all.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (JENA-64) Failed read of imported ontology leaves a memory in the ModelMaker

[Andy Seaborne (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne resolved JENA-64.
---
Resolution: Won't Fix

> Failed read of imported ontology leaves a memory in the ModelMaker
> --
>
> Key: JENA-64
> URL: https://issues.apache.org/jira/browse/JENA-64
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Ontology API
>Reporter: Ian Dickinson
>Assignee: Ian Dickinson
>Priority: Major
>
> If an OntModel tries to create sub-models for imports, and the attempt to 
> read an import fails, an empty model is left associated with the source URL 
> in the memory retained by SimpleGraphMaker. Subsequent attempts to read the 
> import URI, e.g. with a FileManager redirect in place to avoid the network 
> issue, return only the empty model from the failed read and do not read the 
> updated source.
> Failed model reads should not leave a memory in the graph maker. Possibly, 
> graph maker should not have a memory at all.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (JENA-16) A roadmap, a wish list|future features and related W3C recommendations and IETF RFCs

[Andy Seaborne (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne resolved JENA-16.
---
Resolution: Information Provided

JIRA is that list.

> A roadmap, a wish list|future features and related W3C recommendations and 
> IETF RFCs
> 
>
> Key: JENA-16
> URL: https://issues.apache.org/jira/browse/JENA-16
> Project: Apache Jena
>  Issue Type: Task
>  Components: Web site
>Reporter: Paolo Castagna
>Priority: Major
>
> Things I appreciate about open source project websites/documentation are: 
> roadmap pages (i.e. what is going on and, approximately, when it will be 
> done), wish lists and/or feature requests, related 
> specifications/standards/recommendations.
> These are just a few examples taken from other Apache projects:
>  - 
> https://issues.apache.org/jira/browse/MAPREDUCE?report=com.atlassian.jira.plugin.system.project:roadmap-panel
>  - http://wiki.apache.org/pig/PigJournal
>  - http://wiki.apache.org/hadoop/HdfsFutures
>  - http://james.apache.org/server/rfclist.html
> Maybe, it would be good to have a (short) roadmap page for Jena, a (short) 
> wish list and/or future features with clear no commitment and a related W3C 
> recommendations and IETF RFCs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (JENA-16) A roadmap, a wish list|future features and related W3C recommendations and IETF RFCs

[Andy Seaborne (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne closed JENA-16.
-

> A roadmap, a wish list|future features and related W3C recommendations and 
> IETF RFCs
> 
>
> Key: JENA-16
> URL: https://issues.apache.org/jira/browse/JENA-16
> Project: Apache Jena
>  Issue Type: Task
>  Components: Web site
>Reporter: Paolo Castagna
>Priority: Major
>
> Things I appreciate about open source project websites/documentation are: 
> roadmap pages (i.e. what is going on and, approximately, when it will be 
> done), wish lists and/or feature requests, related 
> specifications/standards/recommendations.
> These are just a few examples taken from other Apache projects:
>  - 
> https://issues.apache.org/jira/browse/MAPREDUCE?report=com.atlassian.jira.plugin.system.project:roadmap-panel
>  - http://wiki.apache.org/pig/PigJournal
>  - http://wiki.apache.org/hadoop/HdfsFutures
>  - http://james.apache.org/server/rfclist.html
> Maybe, it would be good to have a (short) roadmap page for Jena, a (short) 
> wish list and/or future features with clear no commitment and a related W3C 
> recommendations and IETF RFCs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (JENA-404) move /testing/regression/testModelEquals to /src/test/resources/testing/regresson/testModelEquals

[Andy Seaborne (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne resolved JENA-404.

   Resolution: Fixed
 Assignee: Claude Warren
Fix Version/s: Jena 3.0.0

It is in {{src/test/resources/regression/testModelEquals}}.

> move /testing/regression/testModelEquals to 
> /src/test/resources/testing/regresson/testModelEquals
> -
>
> Key: JENA-404
> URL: https://issues.apache.org/jira/browse/JENA-404
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Jena
>Affects Versions: Jena 2.7.4, Jena 2.10.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Major
> Fix For: Jena 3.0.0
>
>
> the files /testing/regression/testModelEquals are used in the Model testing 
> framework which is now used outside the Jena application.  Moving the files 
> to  /src/test/resources/testing/regresson/testModelEquals will make them 
> available as part of the test jar without modification to the POM.
> Usage within the tests will need to modified to use URLs loaded via the class 
> loader rather than "file" URLs that access the files directly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (JENA-404) move /testing/regression/testModelEquals to /src/test/resources/testing/regresson/testModelEquals

[Andy Seaborne (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne closed JENA-404.
--

> move /testing/regression/testModelEquals to 
> /src/test/resources/testing/regresson/testModelEquals
> -
>
> Key: JENA-404
> URL: https://issues.apache.org/jira/browse/JENA-404
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Jena
>Affects Versions: Jena 2.7.4, Jena 2.10.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Major
> Fix For: Jena 3.0.0
>
>
> the files /testing/regression/testModelEquals are used in the Model testing 
> framework which is now used outside the Jena application.  Moving the files 
> to  /src/test/resources/testing/regresson/testModelEquals will make them 
> available as part of the test jar without modification to the POM.
> Usage within the tests will need to modified to use URLs loaded via the class 
> loader rather than "file" URLs that access the files directly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1521) TDB2 backed Datasets cannot be re-opened.

[Andy Seaborne (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437941#comment-16437941
 ] 

Andy Seaborne commented on JENA-1521:
-

If a library closes a dataset then it had better put that in its contract. If 
it were a file, then the file is closed and the file position lost. Anyway, now 
TDB1 (when transactional) and TDB2 datasets can be closed. Close was never 
thread/transaction safe because of other threads using a dataset.

The overheads of a dataset are not small. There is a lot of caching going on, 
both in JVM and in the OS file system cache.

Closing does not flush in-memory - the end of write transaction does that (or 
"sync" if TBD, non-transactional).

> TDB2 backed Datasets cannot be re-opened.
> -
>
> Key: JENA-1521
> URL: https://issues.apache.org/jira/browse/JENA-1521
> Project: Apache Jena
>  Issue Type: Bug
> Environment: Apache Jena: 3.7.0
> Java: 1.8_162
>Reporter: Greg Albiston
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.8.0
>
>
> If a Dataset connected to with TDB2Factory.connectDataset() is opened, closed 
> and then later re-opened it is reported that the Dataset is closed.
> Opening, closing and re-opening a Dataset with TDBFactory.createDataset() 
> causes no issues.
> Example code to reproduce:
> {noformat}
> public void testTDB2OpenClose() {
> System.out.println("TDB2 Open Close");
>  try {
>  Dataset dataset = TDB2Factory.connectDataset("test_tdb2");
>  dataset.begin(ReadWrite.WRITE);
>  Model defaultModel = dataset.getDefaultModel();
>  
> defaultModel.add(ResourceFactory.createResource("http://example.org/my#SubjA;),
>  ResourceFactory.createProperty("http://example.org/my#PropA;), 
> ResourceFactory.createResource("http://example.org/my#ObjA;));
>  dataset.commit();
>  dataset.end();
>  dataset.close();
> Dataset dataset2 = TDB2Factory.connectDataset("test_tdb2");
>  dataset2.begin(ReadWrite.READ);
>  Model readModel = dataset2.getDefaultModel();
>  Iterator statements = readModel.listStatements();
>  while (statements.hasNext())
> { Statement statement = statements.next(); System.out.println(statement); }
>  dataset2.end();
>  dataset2.close();
>  } catch (Exception ex) \{ System.out.println("Exception: " + 
> ex.getMessage()); }
>  }
>  {noformat}
> {noformat}
>  public void testTDB1OpenClose() {
>  
>  System.out.println("TDB1 Open Close");
>  try {
>  Dataset dataset = TDBFactory.createDataset("test_tdb1");
>  dataset.begin(ReadWrite.WRITE);
>  Model defaultModel = dataset.getDefaultModel();
>  
> defaultModel.add(ResourceFactory.createResource("http://example.org/my#SubjA;),
>  ResourceFactory.createProperty("http://example.org/my#PropA;), 
> ResourceFactory.createResource("http://example.org/my#ObjA;));
>  dataset.commit();
>  dataset.end();
>  dataset.close();
>  
>  Dataset dataset2 = TDBFactory.createDataset("test_tdb1");
>  dataset2.begin(ReadWrite.READ);
>  Model readModel = dataset2.getDefaultModel();
>  Iterator statements = readModel.listStatements();
>  while (statements.hasNext()) \{ Statement statement = statements.next(); 
> System.out.println(statement); }
> dataset2.end();
>  dataset2.close();
>  } catch (Exception ex)
> { System.out.println("Exception: " + ex.getMessage()); }
> }
> {noformat}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (JENA-1523) "VARS requires a list of variables" exception w/spilling and renamed vars

[Andy Seaborne (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne resolved JENA-1523.
-
   Resolution: Fixed
 Assignee: Andy Seaborne
Fix Version/s: Jena 3.8.0

> "VARS requires a list of variables" exception w/spilling and renamed vars
> -
>
> Key: JENA-1523
> URL: https://issues.apache.org/jira/browse/JENA-1523
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.7.0
>Reporter: Shawn Smith
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.8.0
>
>
> Spilling a {{DistinctDataBag}} or {{SortedDataBag}} when executing SPARQL 
> queries that are modified by {{TransformScopeRename}} can result in the 
> following:
> {noformat}
> org.apache.jena.riot.RiotException: [line: 1, col: 7 ] VARS requires a list 
> of variables (found '[SLASH]')
> at 
> org.apache.jena.riot.system.ErrorHandlerFactory$ErrorHandlerStd.fatal(ErrorHandlerFactory.java:147)
> at org.apache.jena.riot.lang.LangEngine.raiseException(LangEngine.java:148)
> at org.apache.jena.riot.lang.LangEngine.exceptionDirect(LangEngine.java:143)
> at org.apache.jena.riot.lang.LangEngine.exception(LangEngine.java:137)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream.access$1900(BindingInputStream.java:64)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream$IteratorTuples.directiveVars(BindingInputStream.java:227)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream$IteratorTuples.directives(BindingInputStream.java:140)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream$IteratorTuples.(BindingInputStream.java:129)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream.(BindingInputStream.java:99)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream.(BindingInputStream.java:78)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream.(BindingInputStream.java:73)
> at 
> org.apache.jena.riot.system.SerializationFactoryFinder$1.createDeserializer(SerializationFactoryFinder.java:56)
> at 
> org.apache.jena.atlas.data.SortedDataBag.getInputIterator(SortedDataBag.java:190)
> at org.apache.jena.atlas.data.SortedDataBag.iterator(SortedDataBag.java:235)
> at org.apache.jena.atlas.data.SortedDataBag.iterator(SortedDataBag.java:206)
> at 
> org.apache.jena.atlas.data.DistinctDataBag.iterator(DistinctDataBag.java:94){noformat}
> The problem is that renaming variables prepends a "/" so that, for example, 
> the first line of the spill file might look like the following which 
> {{BindingInputStream.directiveVars()}} can't parse:
> {noformat}
> VARS ?/.1 ?/.0 ?v_2 ?v_21 ?v_1 .{noformat}
> Here's a test case that reproduces the exception:
> {noformat}
> @Test
> public void testWithRenamedVars() {
> ExprVar expr = (ExprVar) Rename.renameVars(new ExprVar("1"), 
> Collections.emptySet());
> BindingMap binding = BindingFactory.create();
> binding.add(expr.asVar(), NodeFactory.createLiteral("foo"));
> SortedDataBag dataBag = BagFactory.newSortedBag(
> new ThresholdPolicyCount<>(0),
> SerializationFactoryFinder.bindingSerializationFactory(),
> new BindingComparator(new ArrayList<>()));
> try {
> dataBag.add(binding);
> dataBag.flush();
> // Spill file looks like the following:
> // VARS ?/1 .
> // "foo" .
> Binding actual = dataBag.iterator().next();
> assertEquals(binding, actual);
> } finally {
> dataBag.close();
> }
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (JENA-1520) tdb2.tdbstats

[Andy Seaborne (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-1520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne resolved JENA-1520.
-
Resolution: Fixed

> tdb2.tdbstats
> -
>
> Key: JENA-1520
> URL: https://issues.apache.org/jira/browse/JENA-1520
> Project: Apache Jena
>  Issue Type: Bug
>  Components: TDB2
>Affects Versions: Jena 3.7.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.8.0
>
>
> {{tdb2.tdbstats}} works mostly but breaks when trying to find the 
> {{rdf:type}} node.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1520) tdb2.tdbstats

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437929#comment-16437929
 ] 

ASF GitHub Bot commented on JENA-1520:
--

Github user asfgit closed the pull request at:

https://github.com/apache/jena/pull/396


> tdb2.tdbstats
> -
>
> Key: JENA-1520
> URL: https://issues.apache.org/jira/browse/JENA-1520
> Project: Apache Jena
>  Issue Type: Bug
>  Components: TDB2
>Affects Versions: Jena 3.7.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.8.0
>
>
> {{tdb2.tdbstats}} works mostly but breaks when trying to find the 
> {{rdf:type}} node.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1523) "VARS requires a list of variables" exception w/spilling and renamed vars

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437931#comment-16437931
 ] 

ASF GitHub Bot commented on JENA-1523:
--

Github user asfgit closed the pull request at:

https://github.com/apache/jena/pull/398


> "VARS requires a list of variables" exception w/spilling and renamed vars
> -
>
> Key: JENA-1523
> URL: https://issues.apache.org/jira/browse/JENA-1523
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.7.0
>Reporter: Shawn Smith
>Priority: Major
>
> Spilling a {{DistinctDataBag}} or {{SortedDataBag}} when executing SPARQL 
> queries that are modified by {{TransformScopeRename}} can result in the 
> following:
> {noformat}
> org.apache.jena.riot.RiotException: [line: 1, col: 7 ] VARS requires a list 
> of variables (found '[SLASH]')
> at 
> org.apache.jena.riot.system.ErrorHandlerFactory$ErrorHandlerStd.fatal(ErrorHandlerFactory.java:147)
> at org.apache.jena.riot.lang.LangEngine.raiseException(LangEngine.java:148)
> at org.apache.jena.riot.lang.LangEngine.exceptionDirect(LangEngine.java:143)
> at org.apache.jena.riot.lang.LangEngine.exception(LangEngine.java:137)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream.access$1900(BindingInputStream.java:64)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream$IteratorTuples.directiveVars(BindingInputStream.java:227)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream$IteratorTuples.directives(BindingInputStream.java:140)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream$IteratorTuples.(BindingInputStream.java:129)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream.(BindingInputStream.java:99)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream.(BindingInputStream.java:78)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream.(BindingInputStream.java:73)
> at 
> org.apache.jena.riot.system.SerializationFactoryFinder$1.createDeserializer(SerializationFactoryFinder.java:56)
> at 
> org.apache.jena.atlas.data.SortedDataBag.getInputIterator(SortedDataBag.java:190)
> at org.apache.jena.atlas.data.SortedDataBag.iterator(SortedDataBag.java:235)
> at org.apache.jena.atlas.data.SortedDataBag.iterator(SortedDataBag.java:206)
> at 
> org.apache.jena.atlas.data.DistinctDataBag.iterator(DistinctDataBag.java:94){noformat}
> The problem is that renaming variables prepends a "/" so that, for example, 
> the first line of the spill file might look like the following which 
> {{BindingInputStream.directiveVars()}} can't parse:
> {noformat}
> VARS ?/.1 ?/.0 ?v_2 ?v_21 ?v_1 .{noformat}
> Here's a test case that reproduces the exception:
> {noformat}
> @Test
> public void testWithRenamedVars() {
> ExprVar expr = (ExprVar) Rename.renameVars(new ExprVar("1"), 
> Collections.emptySet());
> BindingMap binding = BindingFactory.create();
> binding.add(expr.asVar(), NodeFactory.createLiteral("foo"));
> SortedDataBag dataBag = BagFactory.newSortedBag(
> new ThresholdPolicyCount<>(0),
> SerializationFactoryFinder.bindingSerializationFactory(),
> new BindingComparator(new ArrayList<>()));
> try {
> dataBag.add(binding);
> dataBag.flush();
> // Spill file looks like the following:
> // VARS ?/1 .
> // "foo" .
> Binding actual = dataBag.iterator().next();
> assertEquals(binding, actual);
> } finally {
> dataBag.close();
> }
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1521) TDB2 backed Datasets cannot be re-opened.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437930#comment-16437930
 ] 

ASF GitHub Bot commented on JENA-1521:
--

Github user asfgit closed the pull request at:

https://github.com/apache/jena/pull/397


> TDB2 backed Datasets cannot be re-opened.
> -
>
> Key: JENA-1521
> URL: https://issues.apache.org/jira/browse/JENA-1521
> Project: Apache Jena
>  Issue Type: Bug
> Environment: Apache Jena: 3.7.0
> Java: 1.8_162
>Reporter: Greg Albiston
>Priority: Major
>
> If a Dataset connected to with TDB2Factory.connectDataset() is opened, closed 
> and then later re-opened it is reported that the Dataset is closed.
> Opening, closing and re-opening a Dataset with TDBFactory.createDataset() 
> causes no issues.
> Example code to reproduce:
> {noformat}
> public void testTDB2OpenClose() {
> System.out.println("TDB2 Open Close");
>  try {
>  Dataset dataset = TDB2Factory.connectDataset("test_tdb2");
>  dataset.begin(ReadWrite.WRITE);
>  Model defaultModel = dataset.getDefaultModel();
>  
> defaultModel.add(ResourceFactory.createResource("http://example.org/my#SubjA;),
>  ResourceFactory.createProperty("http://example.org/my#PropA;), 
> ResourceFactory.createResource("http://example.org/my#ObjA;));
>  dataset.commit();
>  dataset.end();
>  dataset.close();
> Dataset dataset2 = TDB2Factory.connectDataset("test_tdb2");
>  dataset2.begin(ReadWrite.READ);
>  Model readModel = dataset2.getDefaultModel();
>  Iterator statements = readModel.listStatements();
>  while (statements.hasNext())
> { Statement statement = statements.next(); System.out.println(statement); }
>  dataset2.end();
>  dataset2.close();
>  } catch (Exception ex) \{ System.out.println("Exception: " + 
> ex.getMessage()); }
>  }
>  {noformat}
> {noformat}
>  public void testTDB1OpenClose() {
>  
>  System.out.println("TDB1 Open Close");
>  try {
>  Dataset dataset = TDBFactory.createDataset("test_tdb1");
>  dataset.begin(ReadWrite.WRITE);
>  Model defaultModel = dataset.getDefaultModel();
>  
> defaultModel.add(ResourceFactory.createResource("http://example.org/my#SubjA;),
>  ResourceFactory.createProperty("http://example.org/my#PropA;), 
> ResourceFactory.createResource("http://example.org/my#ObjA;));
>  dataset.commit();
>  dataset.end();
>  dataset.close();
>  
>  Dataset dataset2 = TDBFactory.createDataset("test_tdb1");
>  dataset2.begin(ReadWrite.READ);
>  Model readModel = dataset2.getDefaultModel();
>  Iterator statements = readModel.listStatements();
>  while (statements.hasNext()) \{ Statement statement = statements.next(); 
> System.out.println(statement); }
> dataset2.end();
>  dataset2.close();
>  } catch (Exception ex)
> { System.out.println("Exception: " + ex.getMessage()); }
> }
> {noformat}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] jena pull request #398: JENA-1523: Allow internal variables names in variabl...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/jena/pull/398


---

[GitHub] jena pull request #396: JENA-1520: tdb2.tdbstats: cmd and fix for rdf:type

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/jena/pull/396


---

[GitHub] jena pull request #397: JENA-1521: TDB2 tidyup

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/jena/pull/397


---

[jira] [Commented] (JENA-1523) "VARS requires a list of variables" exception w/spilling and renamed vars

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437925#comment-16437925
 ] 

ASF subversion and git services commented on JENA-1523:
---

Commit 991ec09cb1ac24c4c3b3e9d440b426045d2207be in jena's branch 
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=991ec09 ]

JENA-1523: Allow internal variables names in variable parsing.


> "VARS requires a list of variables" exception w/spilling and renamed vars
> -
>
> Key: JENA-1523
> URL: https://issues.apache.org/jira/browse/JENA-1523
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.7.0
>Reporter: Shawn Smith
>Priority: Major
>
> Spilling a {{DistinctDataBag}} or {{SortedDataBag}} when executing SPARQL 
> queries that are modified by {{TransformScopeRename}} can result in the 
> following:
> {noformat}
> org.apache.jena.riot.RiotException: [line: 1, col: 7 ] VARS requires a list 
> of variables (found '[SLASH]')
> at 
> org.apache.jena.riot.system.ErrorHandlerFactory$ErrorHandlerStd.fatal(ErrorHandlerFactory.java:147)
> at org.apache.jena.riot.lang.LangEngine.raiseException(LangEngine.java:148)
> at org.apache.jena.riot.lang.LangEngine.exceptionDirect(LangEngine.java:143)
> at org.apache.jena.riot.lang.LangEngine.exception(LangEngine.java:137)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream.access$1900(BindingInputStream.java:64)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream$IteratorTuples.directiveVars(BindingInputStream.java:227)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream$IteratorTuples.directives(BindingInputStream.java:140)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream$IteratorTuples.(BindingInputStream.java:129)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream.(BindingInputStream.java:99)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream.(BindingInputStream.java:78)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream.(BindingInputStream.java:73)
> at 
> org.apache.jena.riot.system.SerializationFactoryFinder$1.createDeserializer(SerializationFactoryFinder.java:56)
> at 
> org.apache.jena.atlas.data.SortedDataBag.getInputIterator(SortedDataBag.java:190)
> at org.apache.jena.atlas.data.SortedDataBag.iterator(SortedDataBag.java:235)
> at org.apache.jena.atlas.data.SortedDataBag.iterator(SortedDataBag.java:206)
> at 
> org.apache.jena.atlas.data.DistinctDataBag.iterator(DistinctDataBag.java:94){noformat}
> The problem is that renaming variables prepends a "/" so that, for example, 
> the first line of the spill file might look like the following which 
> {{BindingInputStream.directiveVars()}} can't parse:
> {noformat}
> VARS ?/.1 ?/.0 ?v_2 ?v_21 ?v_1 .{noformat}
> Here's a test case that reproduces the exception:
> {noformat}
> @Test
> public void testWithRenamedVars() {
> ExprVar expr = (ExprVar) Rename.renameVars(new ExprVar("1"), 
> Collections.emptySet());
> BindingMap binding = BindingFactory.create();
> binding.add(expr.asVar(), NodeFactory.createLiteral("foo"));
> SortedDataBag dataBag = BagFactory.newSortedBag(
> new ThresholdPolicyCount<>(0),
> SerializationFactoryFinder.bindingSerializationFactory(),
> new BindingComparator(new ArrayList<>()));
> try {
> dataBag.add(binding);
> dataBag.flush();
> // Spill file looks like the following:
> // VARS ?/1 .
> // "foo" .
> Binding actual = dataBag.iterator().next();
> assertEquals(binding, actual);
> } finally {
> dataBag.close();
> }
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1521) TDB2 backed Datasets cannot be re-opened.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437927#comment-16437927
 ] 

ASF subversion and git services commented on JENA-1521:
---

Commit 2341f3f8b1b4b59bc1934564e781de99e51c42e6 in jena's branch 
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=2341f3f ]

JENA-1521: Merge commit 'refs/pull/397/head' of https://github.com/apache/jena

This closes #397.


> TDB2 backed Datasets cannot be re-opened.
> -
>
> Key: JENA-1521
> URL: https://issues.apache.org/jira/browse/JENA-1521
> Project: Apache Jena
>  Issue Type: Bug
> Environment: Apache Jena: 3.7.0
> Java: 1.8_162
>Reporter: Greg Albiston
>Priority: Major
>
> If a Dataset connected to with TDB2Factory.connectDataset() is opened, closed 
> and then later re-opened it is reported that the Dataset is closed.
> Opening, closing and re-opening a Dataset with TDBFactory.createDataset() 
> causes no issues.
> Example code to reproduce:
> {noformat}
> public void testTDB2OpenClose() {
> System.out.println("TDB2 Open Close");
>  try {
>  Dataset dataset = TDB2Factory.connectDataset("test_tdb2");
>  dataset.begin(ReadWrite.WRITE);
>  Model defaultModel = dataset.getDefaultModel();
>  
> defaultModel.add(ResourceFactory.createResource("http://example.org/my#SubjA;),
>  ResourceFactory.createProperty("http://example.org/my#PropA;), 
> ResourceFactory.createResource("http://example.org/my#ObjA;));
>  dataset.commit();
>  dataset.end();
>  dataset.close();
> Dataset dataset2 = TDB2Factory.connectDataset("test_tdb2");
>  dataset2.begin(ReadWrite.READ);
>  Model readModel = dataset2.getDefaultModel();
>  Iterator statements = readModel.listStatements();
>  while (statements.hasNext())
> { Statement statement = statements.next(); System.out.println(statement); }
>  dataset2.end();
>  dataset2.close();
>  } catch (Exception ex) \{ System.out.println("Exception: " + 
> ex.getMessage()); }
>  }
>  {noformat}
> {noformat}
>  public void testTDB1OpenClose() {
>  
>  System.out.println("TDB1 Open Close");
>  try {
>  Dataset dataset = TDBFactory.createDataset("test_tdb1");
>  dataset.begin(ReadWrite.WRITE);
>  Model defaultModel = dataset.getDefaultModel();
>  
> defaultModel.add(ResourceFactory.createResource("http://example.org/my#SubjA;),
>  ResourceFactory.createProperty("http://example.org/my#PropA;), 
> ResourceFactory.createResource("http://example.org/my#ObjA;));
>  dataset.commit();
>  dataset.end();
>  dataset.close();
>  
>  Dataset dataset2 = TDBFactory.createDataset("test_tdb1");
>  dataset2.begin(ReadWrite.READ);
>  Model readModel = dataset2.getDefaultModel();
>  Iterator statements = readModel.listStatements();
>  while (statements.hasNext()) \{ Statement statement = statements.next(); 
> System.out.println(statement); }
> dataset2.end();
>  dataset2.close();
>  } catch (Exception ex)
> { System.out.println("Exception: " + ex.getMessage()); }
> }
> {noformat}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1521) TDB2 backed Datasets cannot be re-opened.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437923#comment-16437923
 ] 

ASF subversion and git services commented on JENA-1521:
---

Commit f6d3c77f32e5ba8c48d2b987dea3915004970eab in jena's branch 
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=f6d3c77 ]

JENA-1521: Don't close. TDB1 and TDB2 datasets are managed differently.

> TDB2 backed Datasets cannot be re-opened.
> -
>
> Key: JENA-1521
> URL: https://issues.apache.org/jira/browse/JENA-1521
> Project: Apache Jena
>  Issue Type: Bug
> Environment: Apache Jena: 3.7.0
> Java: 1.8_162
>Reporter: Greg Albiston
>Priority: Major
>
> If a Dataset connected to with TDB2Factory.connectDataset() is opened, closed 
> and then later re-opened it is reported that the Dataset is closed.
> Opening, closing and re-opening a Dataset with TDBFactory.createDataset() 
> causes no issues.
> Example code to reproduce:
> {noformat}
> public void testTDB2OpenClose() {
> System.out.println("TDB2 Open Close");
>  try {
>  Dataset dataset = TDB2Factory.connectDataset("test_tdb2");
>  dataset.begin(ReadWrite.WRITE);
>  Model defaultModel = dataset.getDefaultModel();
>  
> defaultModel.add(ResourceFactory.createResource("http://example.org/my#SubjA;),
>  ResourceFactory.createProperty("http://example.org/my#PropA;), 
> ResourceFactory.createResource("http://example.org/my#ObjA;));
>  dataset.commit();
>  dataset.end();
>  dataset.close();
> Dataset dataset2 = TDB2Factory.connectDataset("test_tdb2");
>  dataset2.begin(ReadWrite.READ);
>  Model readModel = dataset2.getDefaultModel();
>  Iterator statements = readModel.listStatements();
>  while (statements.hasNext())
> { Statement statement = statements.next(); System.out.println(statement); }
>  dataset2.end();
>  dataset2.close();
>  } catch (Exception ex) \{ System.out.println("Exception: " + 
> ex.getMessage()); }
>  }
>  {noformat}
> {noformat}
>  public void testTDB1OpenClose() {
>  
>  System.out.println("TDB1 Open Close");
>  try {
>  Dataset dataset = TDBFactory.createDataset("test_tdb1");
>  dataset.begin(ReadWrite.WRITE);
>  Model defaultModel = dataset.getDefaultModel();
>  
> defaultModel.add(ResourceFactory.createResource("http://example.org/my#SubjA;),
>  ResourceFactory.createProperty("http://example.org/my#PropA;), 
> ResourceFactory.createResource("http://example.org/my#ObjA;));
>  dataset.commit();
>  dataset.end();
>  dataset.close();
>  
>  Dataset dataset2 = TDBFactory.createDataset("test_tdb1");
>  dataset2.begin(ReadWrite.READ);
>  Model readModel = dataset2.getDefaultModel();
>  Iterator statements = readModel.listStatements();
>  while (statements.hasNext()) \{ Statement statement = statements.next(); 
> System.out.println(statement); }
> dataset2.end();
>  dataset2.close();
>  } catch (Exception ex)
> { System.out.println("Exception: " + ex.getMessage()); }
> }
> {noformat}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1521) TDB2 backed Datasets cannot be re-opened.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437924#comment-16437924
 ] 

ASF subversion and git services commented on JENA-1521:
---

Commit 67b18af43f54814f66f63c13866556b4256e459c in jena's branch 
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=67b18af ]

JENA-1521: Only really close if non-transactional


> TDB2 backed Datasets cannot be re-opened.
> -
>
> Key: JENA-1521
> URL: https://issues.apache.org/jira/browse/JENA-1521
> Project: Apache Jena
>  Issue Type: Bug
> Environment: Apache Jena: 3.7.0
> Java: 1.8_162
>Reporter: Greg Albiston
>Priority: Major
>
> If a Dataset connected to with TDB2Factory.connectDataset() is opened, closed 
> and then later re-opened it is reported that the Dataset is closed.
> Opening, closing and re-opening a Dataset with TDBFactory.createDataset() 
> causes no issues.
> Example code to reproduce:
> {noformat}
> public void testTDB2OpenClose() {
> System.out.println("TDB2 Open Close");
>  try {
>  Dataset dataset = TDB2Factory.connectDataset("test_tdb2");
>  dataset.begin(ReadWrite.WRITE);
>  Model defaultModel = dataset.getDefaultModel();
>  
> defaultModel.add(ResourceFactory.createResource("http://example.org/my#SubjA;),
>  ResourceFactory.createProperty("http://example.org/my#PropA;), 
> ResourceFactory.createResource("http://example.org/my#ObjA;));
>  dataset.commit();
>  dataset.end();
>  dataset.close();
> Dataset dataset2 = TDB2Factory.connectDataset("test_tdb2");
>  dataset2.begin(ReadWrite.READ);
>  Model readModel = dataset2.getDefaultModel();
>  Iterator statements = readModel.listStatements();
>  while (statements.hasNext())
> { Statement statement = statements.next(); System.out.println(statement); }
>  dataset2.end();
>  dataset2.close();
>  } catch (Exception ex) \{ System.out.println("Exception: " + 
> ex.getMessage()); }
>  }
>  {noformat}
> {noformat}
>  public void testTDB1OpenClose() {
>  
>  System.out.println("TDB1 Open Close");
>  try {
>  Dataset dataset = TDBFactory.createDataset("test_tdb1");
>  dataset.begin(ReadWrite.WRITE);
>  Model defaultModel = dataset.getDefaultModel();
>  
> defaultModel.add(ResourceFactory.createResource("http://example.org/my#SubjA;),
>  ResourceFactory.createProperty("http://example.org/my#PropA;), 
> ResourceFactory.createResource("http://example.org/my#ObjA;));
>  dataset.commit();
>  dataset.end();
>  dataset.close();
>  
>  Dataset dataset2 = TDBFactory.createDataset("test_tdb1");
>  dataset2.begin(ReadWrite.READ);
>  Model readModel = dataset2.getDefaultModel();
>  Iterator statements = readModel.listStatements();
>  while (statements.hasNext()) \{ Statement statement = statements.next(); 
> System.out.println(statement); }
> dataset2.end();
>  dataset2.close();
>  } catch (Exception ex)
> { System.out.println("Exception: " + ex.getMessage()); }
> }
> {noformat}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1523) "VARS requires a list of variables" exception w/spilling and renamed vars

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437928#comment-16437928
 ] 

ASF subversion and git services commented on JENA-1523:
---

Commit bea3495877820e2ba55f258e1752dd3c353e3412 in jena's branch 
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=bea3495 ]

JENA-1523: Merge commit 'refs/pull/398/head' of https://github.com/apache/jena

Ths closes #398.


> "VARS requires a list of variables" exception w/spilling and renamed vars
> -
>
> Key: JENA-1523
> URL: https://issues.apache.org/jira/browse/JENA-1523
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.7.0
>Reporter: Shawn Smith
>Priority: Major
>
> Spilling a {{DistinctDataBag}} or {{SortedDataBag}} when executing SPARQL 
> queries that are modified by {{TransformScopeRename}} can result in the 
> following:
> {noformat}
> org.apache.jena.riot.RiotException: [line: 1, col: 7 ] VARS requires a list 
> of variables (found '[SLASH]')
> at 
> org.apache.jena.riot.system.ErrorHandlerFactory$ErrorHandlerStd.fatal(ErrorHandlerFactory.java:147)
> at org.apache.jena.riot.lang.LangEngine.raiseException(LangEngine.java:148)
> at org.apache.jena.riot.lang.LangEngine.exceptionDirect(LangEngine.java:143)
> at org.apache.jena.riot.lang.LangEngine.exception(LangEngine.java:137)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream.access$1900(BindingInputStream.java:64)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream$IteratorTuples.directiveVars(BindingInputStream.java:227)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream$IteratorTuples.directives(BindingInputStream.java:140)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream$IteratorTuples.(BindingInputStream.java:129)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream.(BindingInputStream.java:99)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream.(BindingInputStream.java:78)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream.(BindingInputStream.java:73)
> at 
> org.apache.jena.riot.system.SerializationFactoryFinder$1.createDeserializer(SerializationFactoryFinder.java:56)
> at 
> org.apache.jena.atlas.data.SortedDataBag.getInputIterator(SortedDataBag.java:190)
> at org.apache.jena.atlas.data.SortedDataBag.iterator(SortedDataBag.java:235)
> at org.apache.jena.atlas.data.SortedDataBag.iterator(SortedDataBag.java:206)
> at 
> org.apache.jena.atlas.data.DistinctDataBag.iterator(DistinctDataBag.java:94){noformat}
> The problem is that renaming variables prepends a "/" so that, for example, 
> the first line of the spill file might look like the following which 
> {{BindingInputStream.directiveVars()}} can't parse:
> {noformat}
> VARS ?/.1 ?/.0 ?v_2 ?v_21 ?v_1 .{noformat}
> Here's a test case that reproduces the exception:
> {noformat}
> @Test
> public void testWithRenamedVars() {
> ExprVar expr = (ExprVar) Rename.renameVars(new ExprVar("1"), 
> Collections.emptySet());
> BindingMap binding = BindingFactory.create();
> binding.add(expr.asVar(), NodeFactory.createLiteral("foo"));
> SortedDataBag dataBag = BagFactory.newSortedBag(
> new ThresholdPolicyCount<>(0),
> SerializationFactoryFinder.bindingSerializationFactory(),
> new BindingComparator(new ArrayList<>()));
> try {
> dataBag.add(binding);
> dataBag.flush();
> // Spill file looks like the following:
> // VARS ?/1 .
> // "foo" .
> Binding actual = dataBag.iterator().next();
> assertEquals(binding, actual);
> } finally {
> dataBag.close();
> }
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1520) tdb2.tdbstats

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437926#comment-16437926
 ] 

ASF subversion and git services commented on JENA-1520:
---

Commit 6b6a01b7a2cbc429f968a2cd457c60f9d39e6dad in jena's branch 
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=6b6a01b ]

JENA-1520: Merge commit 'refs/pull/396/head' of https://github.com/apache/jena

This closes #396.


> tdb2.tdbstats
> -
>
> Key: JENA-1520
> URL: https://issues.apache.org/jira/browse/JENA-1520
> Project: Apache Jena
>  Issue Type: Bug
>  Components: TDB2
>Affects Versions: Jena 3.7.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.8.0
>
>
> {{tdb2.tdbstats}} works mostly but breaks when trying to find the 
> {{rdf:type}} node.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1520) tdb2.tdbstats

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437922#comment-16437922
 ] 

ASF subversion and git services commented on JENA-1520:
---

Commit 55516f717caba7d41c4b78ca298f4c030cedcddf in jena's branch 
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=55516f7 ]

JENA-1520: tdb2.tdbstats: cmd and fix for rdf:type


> tdb2.tdbstats
> -
>
> Key: JENA-1520
> URL: https://issues.apache.org/jira/browse/JENA-1520
> Project: Apache Jena
>  Issue Type: Bug
>  Components: TDB2
>Affects Versions: Jena 3.7.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.8.0
>
>
> {{tdb2.tdbstats}} works mostly but breaks when trying to find the 
> {{rdf:type}} node.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1521) TDB2 backed Datasets cannot be re-opened.

[Greg Albiston (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437775#comment-16437775
 ] 

Greg Albiston commented on JENA-1521:
-

Hi Andy,

I understand what your saying about not using it again and the create/destroy 
pattern. However, should there not be some way to reverse a closure without an 
application restarting? There is no obvious method on the Dataset. What if a 
dataset is passed into a third party library which closes it?

Also, how are resources associated with opening the dataset released? For 
example, open the dataset, do some work, go away for a long time, come back and 
reopen. There might only be a small overhead but a developer may wish to they 
are being well behaved and ensuring an in-memory caching is flushed.

>From what you've mentioned the semantics of Datasets are close and can NEVER 
>be accessed again but QueryIterators are MUST close after use to avoid wasting 
>resources.

It just seems strange,

Greg

> TDB2 backed Datasets cannot be re-opened.
> -
>
> Key: JENA-1521
> URL: https://issues.apache.org/jira/browse/JENA-1521
> Project: Apache Jena
>  Issue Type: Bug
> Environment: Apache Jena: 3.7.0
> Java: 1.8_162
>Reporter: Greg Albiston
>Priority: Major
>
> If a Dataset connected to with TDB2Factory.connectDataset() is opened, closed 
> and then later re-opened it is reported that the Dataset is closed.
> Opening, closing and re-opening a Dataset with TDBFactory.createDataset() 
> causes no issues.
> Example code to reproduce:
> {noformat}
> public void testTDB2OpenClose() {
> System.out.println("TDB2 Open Close");
>  try {
>  Dataset dataset = TDB2Factory.connectDataset("test_tdb2");
>  dataset.begin(ReadWrite.WRITE);
>  Model defaultModel = dataset.getDefaultModel();
>  
> defaultModel.add(ResourceFactory.createResource("http://example.org/my#SubjA;),
>  ResourceFactory.createProperty("http://example.org/my#PropA;), 
> ResourceFactory.createResource("http://example.org/my#ObjA;));
>  dataset.commit();
>  dataset.end();
>  dataset.close();
> Dataset dataset2 = TDB2Factory.connectDataset("test_tdb2");
>  dataset2.begin(ReadWrite.READ);
>  Model readModel = dataset2.getDefaultModel();
>  Iterator statements = readModel.listStatements();
>  while (statements.hasNext())
> { Statement statement = statements.next(); System.out.println(statement); }
>  dataset2.end();
>  dataset2.close();
>  } catch (Exception ex) \{ System.out.println("Exception: " + 
> ex.getMessage()); }
>  }
>  {noformat}
> {noformat}
>  public void testTDB1OpenClose() {
>  
>  System.out.println("TDB1 Open Close");
>  try {
>  Dataset dataset = TDBFactory.createDataset("test_tdb1");
>  dataset.begin(ReadWrite.WRITE);
>  Model defaultModel = dataset.getDefaultModel();
>  
> defaultModel.add(ResourceFactory.createResource("http://example.org/my#SubjA;),
>  ResourceFactory.createProperty("http://example.org/my#PropA;), 
> ResourceFactory.createResource("http://example.org/my#ObjA;));
>  dataset.commit();
>  dataset.end();
>  dataset.close();
>  
>  Dataset dataset2 = TDBFactory.createDataset("test_tdb1");
>  dataset2.begin(ReadWrite.READ);
>  Model readModel = dataset2.getDefaultModel();
>  Iterator statements = readModel.listStatements();
>  while (statements.hasNext()) \{ Statement statement = statements.next(); 
> System.out.println(statement); }
> dataset2.end();
>  dataset2.close();
>  } catch (Exception ex)
> { System.out.println("Exception: " + ex.getMessage()); }
> }
> {noformat}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1520) tdb2.tdbstats

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437688#comment-16437688
 ] 

ASF GitHub Bot commented on JENA-1520:
--

Github user afs commented on a diff in the pull request:

https://github.com/apache/jena/pull/396#discussion_r181468935
  
--- Diff: 
jena-db/jena-tdb2/src/main/java/org/apache/jena/tdb2/solver/stats/StatsCollectorNodeId.java
 ---
@@ -18,39 +18,39 @@
 
 package org.apache.jena.tdb2.solver.stats;
 
-import java.util.HashMap ;
-import java.util.Map ;
+import java.util.HashMap;
+import java.util.Map;
 
-import org.apache.jena.graph.Node ;
-import org.apache.jena.sparql.graph.NodeConst ;
+import org.apache.jena.graph.Node;
+import org.apache.jena.sparql.graph.NodeConst;
 import org.apache.jena.tdb2.store.NodeId;
 import org.apache.jena.tdb2.store.nodetable.NodeTable;
 
 /** Statistics collector, aggregates based on NodeId */
-public class StatsCollectorNodeId extends StatsCollectorBase
-{
-private NodeTable nodeTable ;
-
-public StatsCollectorNodeId(NodeTable nodeTable)
-{
-super(findRDFType(nodeTable)) ;
-this.nodeTable = nodeTable ;
+public class StatsCollectorNodeId extends StatsCollectorBase {
+private NodeTable nodeTable;
+
+public StatsCollectorNodeId(NodeTable nodeTable) {
+super(findRDFType(nodeTable));
+this.nodeTable = nodeTable;
 }
-
-private static NodeId findRDFType(NodeTable nodeTable2)
-{
-return nodeTable2.getAllocateNodeId(NodeConst.nodeRDFType) ;
+
+private static NodeId findRDFType(NodeTable nodeTable) {
+// It may not exist.
+NodeId nodeId = nodeTable.getNodeIdForNode(NodeConst.nodeRDFType);
+if ( NodeId.isDoesNotExist(nodeId) )
--- End diff --

Yes, that's right.  The stats engine gathers details for `rdf:type` 
specially so it needs to know the trigger for that. `StatsCollectorBase` is a 
generic and works on an index scan, no touching the node table for every tuple 
of a triple/quad. Here, it's a `NodeId`. if it isn't in the node table, it is 
not in the data.

As it was, it tried to update the node table to add the `rdf:type`, but it 
is in a read transaction so `NodeTable.getAllocateNodeId` fails.



> tdb2.tdbstats
> -
>
> Key: JENA-1520
> URL: https://issues.apache.org/jira/browse/JENA-1520
> Project: Apache Jena
>  Issue Type: Bug
>  Components: TDB2
>Affects Versions: Jena 3.7.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.8.0
>
>
> {{tdb2.tdbstats}} works mostly but breaks when trying to find the 
> {{rdf:type}} node.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] jena pull request #396: JENA-1520: tdb2.tdbstats: cmd and fix for rdf:type

[afs]

Github user afs commented on a diff in the pull request:

https://github.com/apache/jena/pull/396#discussion_r181468935
  
--- Diff: 
jena-db/jena-tdb2/src/main/java/org/apache/jena/tdb2/solver/stats/StatsCollectorNodeId.java
 ---
@@ -18,39 +18,39 @@
 
 package org.apache.jena.tdb2.solver.stats;
 
-import java.util.HashMap ;
-import java.util.Map ;
+import java.util.HashMap;
+import java.util.Map;
 
-import org.apache.jena.graph.Node ;
-import org.apache.jena.sparql.graph.NodeConst ;
+import org.apache.jena.graph.Node;
+import org.apache.jena.sparql.graph.NodeConst;
 import org.apache.jena.tdb2.store.NodeId;
 import org.apache.jena.tdb2.store.nodetable.NodeTable;
 
 /** Statistics collector, aggregates based on NodeId */
-public class StatsCollectorNodeId extends StatsCollectorBase
-{
-private NodeTable nodeTable ;
-
-public StatsCollectorNodeId(NodeTable nodeTable)
-{
-super(findRDFType(nodeTable)) ;
-this.nodeTable = nodeTable ;
+public class StatsCollectorNodeId extends StatsCollectorBase {
+private NodeTable nodeTable;
+
+public StatsCollectorNodeId(NodeTable nodeTable) {
+super(findRDFType(nodeTable));
+this.nodeTable = nodeTable;
 }
-
-private static NodeId findRDFType(NodeTable nodeTable2)
-{
-return nodeTable2.getAllocateNodeId(NodeConst.nodeRDFType) ;
+
+private static NodeId findRDFType(NodeTable nodeTable) {
+// It may not exist.
+NodeId nodeId = nodeTable.getNodeIdForNode(NodeConst.nodeRDFType);
+if ( NodeId.isDoesNotExist(nodeId) )
--- End diff --

Yes, that's right.  The stats engine gathers details for `rdf:type` 
specially so it needs to know the trigger for that. `StatsCollectorBase` is a 
generic and works on an index scan, no touching the node table for every tuple 
of a triple/quad. Here, it's a `NodeId`. if it isn't in the node table, it is 
not in the data.

As it was, it tried to update the node table to add the `rdf:type`, but it 
is in a read transaction so `NodeTable.getAllocateNodeId` fails.



---

[jira] [Commented] (JENA-1520) tdb2.tdbstats

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437623#comment-16437623
 ] 

ASF GitHub Bot commented on JENA-1520:
--

Github user ajs6f commented on a diff in the pull request:

https://github.com/apache/jena/pull/396#discussion_r181458378
  
--- Diff: 
jena-db/jena-tdb2/src/main/java/org/apache/jena/tdb2/solver/stats/StatsCollectorNodeId.java
 ---
@@ -18,39 +18,39 @@
 
 package org.apache.jena.tdb2.solver.stats;
 
-import java.util.HashMap ;
-import java.util.Map ;
+import java.util.HashMap;
+import java.util.Map;
 
-import org.apache.jena.graph.Node ;
-import org.apache.jena.sparql.graph.NodeConst ;
+import org.apache.jena.graph.Node;
+import org.apache.jena.sparql.graph.NodeConst;
 import org.apache.jena.tdb2.store.NodeId;
 import org.apache.jena.tdb2.store.nodetable.NodeTable;
 
 /** Statistics collector, aggregates based on NodeId */
-public class StatsCollectorNodeId extends StatsCollectorBase
-{
-private NodeTable nodeTable ;
-
-public StatsCollectorNodeId(NodeTable nodeTable)
-{
-super(findRDFType(nodeTable)) ;
-this.nodeTable = nodeTable ;
+public class StatsCollectorNodeId extends StatsCollectorBase {
+private NodeTable nodeTable;
+
+public StatsCollectorNodeId(NodeTable nodeTable) {
+super(findRDFType(nodeTable));
+this.nodeTable = nodeTable;
 }
-
-private static NodeId findRDFType(NodeTable nodeTable2)
-{
-return nodeTable2.getAllocateNodeId(NodeConst.nodeRDFType) ;
+
+private static NodeId findRDFType(NodeTable nodeTable) {
+// It may not exist.
+NodeId nodeId = nodeTable.getNodeIdForNode(NodeConst.nodeRDFType);
+if ( NodeId.isDoesNotExist(nodeId) )
--- End diff --

Jut for my own education-- am I right in understanding this to be the fix 
for the "no type triples in the data" problem?


> tdb2.tdbstats
> -
>
> Key: JENA-1520
> URL: https://issues.apache.org/jira/browse/JENA-1520
> Project: Apache Jena
>  Issue Type: Bug
>  Components: TDB2
>Affects Versions: Jena 3.7.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.8.0
>
>
> {{tdb2.tdbstats}} works mostly but breaks when trying to find the 
> {{rdf:type}} node.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] jena pull request #396: JENA-1520: tdb2.tdbstats: cmd and fix for rdf:type

[ajs6f]

Github user ajs6f commented on a diff in the pull request:

https://github.com/apache/jena/pull/396#discussion_r181458378
  
--- Diff: 
jena-db/jena-tdb2/src/main/java/org/apache/jena/tdb2/solver/stats/StatsCollectorNodeId.java
 ---
@@ -18,39 +18,39 @@
 
 package org.apache.jena.tdb2.solver.stats;
 
-import java.util.HashMap ;
-import java.util.Map ;
+import java.util.HashMap;
+import java.util.Map;
 
-import org.apache.jena.graph.Node ;
-import org.apache.jena.sparql.graph.NodeConst ;
+import org.apache.jena.graph.Node;
+import org.apache.jena.sparql.graph.NodeConst;
 import org.apache.jena.tdb2.store.NodeId;
 import org.apache.jena.tdb2.store.nodetable.NodeTable;
 
 /** Statistics collector, aggregates based on NodeId */
-public class StatsCollectorNodeId extends StatsCollectorBase
-{
-private NodeTable nodeTable ;
-
-public StatsCollectorNodeId(NodeTable nodeTable)
-{
-super(findRDFType(nodeTable)) ;
-this.nodeTable = nodeTable ;
+public class StatsCollectorNodeId extends StatsCollectorBase {
+private NodeTable nodeTable;
+
+public StatsCollectorNodeId(NodeTable nodeTable) {
+super(findRDFType(nodeTable));
+this.nodeTable = nodeTable;
 }
-
-private static NodeId findRDFType(NodeTable nodeTable2)
-{
-return nodeTable2.getAllocateNodeId(NodeConst.nodeRDFType) ;
+
+private static NodeId findRDFType(NodeTable nodeTable) {
+// It may not exist.
+NodeId nodeId = nodeTable.getNodeIdForNode(NodeConst.nodeRDFType);
+if ( NodeId.isDoesNotExist(nodeId) )
--- End diff --

Jut for my own education-- am I right in understanding this to be the fix 
for the "no type triples in the data" problem?


---

[jira] [Commented] (JENA-1523) "VARS requires a list of variables" exception w/spilling and renamed vars

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437608#comment-16437608
 ] 

ASF GitHub Bot commented on JENA-1523:
--

Github user afs commented on a diff in the pull request:

https://github.com/apache/jena/pull/398#discussion_r181455972
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/riot/tokens/TokenizerText.java ---
@@ -739,16 +739,21 @@ private String readWordSub(boolean 
leadingDigitAllowed, boolean leadingSignAllow
 return readCharsAnd(leadingDigitAllowed, leadingSignAllowed, 
extraCharsWord, false);
 }
 
-static private char[] extraCharsVar = new char[]{'_', '.', '-', '?', 
'@', '+'};
+// This array adds the other characters that can occurs in an internal 
variable name.
+// Variable a creeated with SPARQL-illegal syntax to encsure they do 
not clash with
--- End diff --

Fixed!


> "VARS requires a list of variables" exception w/spilling and renamed vars
> -
>
> Key: JENA-1523
> URL: https://issues.apache.org/jira/browse/JENA-1523
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.7.0
>Reporter: Shawn Smith
>Priority: Major
>
> Spilling a {{DistinctDataBag}} or {{SortedDataBag}} when executing SPARQL 
> queries that are modified by {{TransformScopeRename}} can result in the 
> following:
> {noformat}
> org.apache.jena.riot.RiotException: [line: 1, col: 7 ] VARS requires a list 
> of variables (found '[SLASH]')
> at 
> org.apache.jena.riot.system.ErrorHandlerFactory$ErrorHandlerStd.fatal(ErrorHandlerFactory.java:147)
> at org.apache.jena.riot.lang.LangEngine.raiseException(LangEngine.java:148)
> at org.apache.jena.riot.lang.LangEngine.exceptionDirect(LangEngine.java:143)
> at org.apache.jena.riot.lang.LangEngine.exception(LangEngine.java:137)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream.access$1900(BindingInputStream.java:64)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream$IteratorTuples.directiveVars(BindingInputStream.java:227)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream$IteratorTuples.directives(BindingInputStream.java:140)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream$IteratorTuples.(BindingInputStream.java:129)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream.(BindingInputStream.java:99)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream.(BindingInputStream.java:78)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream.(BindingInputStream.java:73)
> at 
> org.apache.jena.riot.system.SerializationFactoryFinder$1.createDeserializer(SerializationFactoryFinder.java:56)
> at 
> org.apache.jena.atlas.data.SortedDataBag.getInputIterator(SortedDataBag.java:190)
> at org.apache.jena.atlas.data.SortedDataBag.iterator(SortedDataBag.java:235)
> at org.apache.jena.atlas.data.SortedDataBag.iterator(SortedDataBag.java:206)
> at 
> org.apache.jena.atlas.data.DistinctDataBag.iterator(DistinctDataBag.java:94){noformat}
> The problem is that renaming variables prepends a "/" so that, for example, 
> the first line of the spill file might look like the following which 
> {{BindingInputStream.directiveVars()}} can't parse:
> {noformat}
> VARS ?/.1 ?/.0 ?v_2 ?v_21 ?v_1 .{noformat}
> Here's a test case that reproduces the exception:
> {noformat}
> @Test
> public void testWithRenamedVars() {
> ExprVar expr = (ExprVar) Rename.renameVars(new ExprVar("1"), 
> Collections.emptySet());
> BindingMap binding = BindingFactory.create();
> binding.add(expr.asVar(), NodeFactory.createLiteral("foo"));
> SortedDataBag dataBag = BagFactory.newSortedBag(
> new ThresholdPolicyCount<>(0),
> SerializationFactoryFinder.bindingSerializationFactory(),
> new BindingComparator(new ArrayList<>()));
> try {
> dataBag.add(binding);
> dataBag.flush();
> // Spill file looks like the following:
> // VARS ?/1 .
> // "foo" .
> Binding actual = dataBag.iterator().next();
> assertEquals(binding, actual);
> } finally {
> dataBag.close();
> }
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] jena pull request #398: JENA-1523: Allow internal variables names in variabl...

[afs]

Github user afs commented on a diff in the pull request:

https://github.com/apache/jena/pull/398#discussion_r181455972
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/riot/tokens/TokenizerText.java ---
@@ -739,16 +739,21 @@ private String readWordSub(boolean 
leadingDigitAllowed, boolean leadingSignAllow
 return readCharsAnd(leadingDigitAllowed, leadingSignAllowed, 
extraCharsWord, false);
 }
 
-static private char[] extraCharsVar = new char[]{'_', '.', '-', '?', 
'@', '+'};
+// This array adds the other characters that can occurs in an internal 
variable name.
+// Variable a creeated with SPARQL-illegal syntax to encsure they do 
not clash with
--- End diff --

Fixed!


---

[jira] [Commented] (JENA-1523) "VARS requires a list of variables" exception w/spilling and renamed vars

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437606#comment-16437606
 ] 

ASF GitHub Bot commented on JENA-1523:
--

Github user ajs6f commented on a diff in the pull request:

https://github.com/apache/jena/pull/398#discussion_r181455157
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/riot/tokens/TokenizerText.java ---
@@ -739,16 +739,21 @@ private String readWordSub(boolean 
leadingDigitAllowed, boolean leadingSignAllow
 return readCharsAnd(leadingDigitAllowed, leadingSignAllowed, 
extraCharsWord, false);
 }
 
-static private char[] extraCharsVar = new char[]{'_', '.', '-', '?', 
'@', '+'};
+// This array adds the other characters that can occurs in an internal 
variable name.
+// Variable a creeated with SPARQL-illegal syntax to encsure they do 
not clash with
--- End diff --

typos, can be line-changed to:
```
Variables are created with SPARQL-illegal syntax to ensure that they do not 
clash with
```


> "VARS requires a list of variables" exception w/spilling and renamed vars
> -
>
> Key: JENA-1523
> URL: https://issues.apache.org/jira/browse/JENA-1523
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.7.0
>Reporter: Shawn Smith
>Priority: Major
>
> Spilling a {{DistinctDataBag}} or {{SortedDataBag}} when executing SPARQL 
> queries that are modified by {{TransformScopeRename}} can result in the 
> following:
> {noformat}
> org.apache.jena.riot.RiotException: [line: 1, col: 7 ] VARS requires a list 
> of variables (found '[SLASH]')
> at 
> org.apache.jena.riot.system.ErrorHandlerFactory$ErrorHandlerStd.fatal(ErrorHandlerFactory.java:147)
> at org.apache.jena.riot.lang.LangEngine.raiseException(LangEngine.java:148)
> at org.apache.jena.riot.lang.LangEngine.exceptionDirect(LangEngine.java:143)
> at org.apache.jena.riot.lang.LangEngine.exception(LangEngine.java:137)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream.access$1900(BindingInputStream.java:64)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream$IteratorTuples.directiveVars(BindingInputStream.java:227)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream$IteratorTuples.directives(BindingInputStream.java:140)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream$IteratorTuples.(BindingInputStream.java:129)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream.(BindingInputStream.java:99)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream.(BindingInputStream.java:78)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream.(BindingInputStream.java:73)
> at 
> org.apache.jena.riot.system.SerializationFactoryFinder$1.createDeserializer(SerializationFactoryFinder.java:56)
> at 
> org.apache.jena.atlas.data.SortedDataBag.getInputIterator(SortedDataBag.java:190)
> at org.apache.jena.atlas.data.SortedDataBag.iterator(SortedDataBag.java:235)
> at org.apache.jena.atlas.data.SortedDataBag.iterator(SortedDataBag.java:206)
> at 
> org.apache.jena.atlas.data.DistinctDataBag.iterator(DistinctDataBag.java:94){noformat}
> The problem is that renaming variables prepends a "/" so that, for example, 
> the first line of the spill file might look like the following which 
> {{BindingInputStream.directiveVars()}} can't parse:
> {noformat}
> VARS ?/.1 ?/.0 ?v_2 ?v_21 ?v_1 .{noformat}
> Here's a test case that reproduces the exception:
> {noformat}
> @Test
> public void testWithRenamedVars() {
> ExprVar expr = (ExprVar) Rename.renameVars(new ExprVar("1"), 
> Collections.emptySet());
> BindingMap binding = BindingFactory.create();
> binding.add(expr.asVar(), NodeFactory.createLiteral("foo"));
> SortedDataBag dataBag = BagFactory.newSortedBag(
> new ThresholdPolicyCount<>(0),
> SerializationFactoryFinder.bindingSerializationFactory(),
> new BindingComparator(new ArrayList<>()));
> try {
> dataBag.add(binding);
> dataBag.flush();
> // Spill file looks like the following:
> // VARS ?/1 .
> // "foo" .
> Binding actual = dataBag.iterator().next();
> assertEquals(binding, actual);
> } finally {
> dataBag.close();
> }
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] jena pull request #398: JENA-1523: Allow internal variables names in variabl...

[ajs6f]

Github user ajs6f commented on a diff in the pull request:

https://github.com/apache/jena/pull/398#discussion_r181455157
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/riot/tokens/TokenizerText.java ---
@@ -739,16 +739,21 @@ private String readWordSub(boolean 
leadingDigitAllowed, boolean leadingSignAllow
 return readCharsAnd(leadingDigitAllowed, leadingSignAllowed, 
extraCharsWord, false);
 }
 
-static private char[] extraCharsVar = new char[]{'_', '.', '-', '?', 
'@', '+'};
+// This array adds the other characters that can occurs in an internal 
variable name.
+// Variable a creeated with SPARQL-illegal syntax to encsure they do 
not clash with
--- End diff --

typos, can be line-changed to:
```
Variables are created with SPARQL-illegal syntax to ensure that they do not 
clash with
```


---

[jira] [Commented] (JENA-1523) "VARS requires a list of variables" exception w/spilling and renamed vars

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437595#comment-16437595
 ] 

ASF GitHub Bot commented on JENA-1523:
--

GitHub user afs opened a pull request:

https://github.com/apache/jena/pull/398

JENA-1523: Allow internal variables names in variable parsing.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/afs/jena var-databag

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/jena/pull/398.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #398


commit 6a9ad3401cb3cf3326489adc2be4d89d2dc40b8e
Author: Andy Seaborne 
Date:   2018-04-13T16:53:48Z

JENA-1523: Allow internal variables names in variable parsing.




> "VARS requires a list of variables" exception w/spilling and renamed vars
> -
>
> Key: JENA-1523
> URL: https://issues.apache.org/jira/browse/JENA-1523
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.7.0
>Reporter: Shawn Smith
>Priority: Major
>
> Spilling a {{DistinctDataBag}} or {{SortedDataBag}} when executing SPARQL 
> queries that are modified by {{TransformScopeRename}} can result in the 
> following:
> {noformat}
> org.apache.jena.riot.RiotException: [line: 1, col: 7 ] VARS requires a list 
> of variables (found '[SLASH]')
> at 
> org.apache.jena.riot.system.ErrorHandlerFactory$ErrorHandlerStd.fatal(ErrorHandlerFactory.java:147)
> at org.apache.jena.riot.lang.LangEngine.raiseException(LangEngine.java:148)
> at org.apache.jena.riot.lang.LangEngine.exceptionDirect(LangEngine.java:143)
> at org.apache.jena.riot.lang.LangEngine.exception(LangEngine.java:137)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream.access$1900(BindingInputStream.java:64)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream$IteratorTuples.directiveVars(BindingInputStream.java:227)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream$IteratorTuples.directives(BindingInputStream.java:140)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream$IteratorTuples.(BindingInputStream.java:129)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream.(BindingInputStream.java:99)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream.(BindingInputStream.java:78)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream.(BindingInputStream.java:73)
> at 
> org.apache.jena.riot.system.SerializationFactoryFinder$1.createDeserializer(SerializationFactoryFinder.java:56)
> at 
> org.apache.jena.atlas.data.SortedDataBag.getInputIterator(SortedDataBag.java:190)
> at org.apache.jena.atlas.data.SortedDataBag.iterator(SortedDataBag.java:235)
> at org.apache.jena.atlas.data.SortedDataBag.iterator(SortedDataBag.java:206)
> at 
> org.apache.jena.atlas.data.DistinctDataBag.iterator(DistinctDataBag.java:94){noformat}
> The problem is that renaming variables prepends a "/" so that, for example, 
> the first line of the spill file might look like the following which 
> {{BindingInputStream.directiveVars()}} can't parse:
> {noformat}
> VARS ?/.1 ?/.0 ?v_2 ?v_21 ?v_1 .{noformat}
> Here's a test case that reproduces the exception:
> {noformat}
> @Test
> public void testWithRenamedVars() {
> ExprVar expr = (ExprVar) Rename.renameVars(new ExprVar("1"), 
> Collections.emptySet());
> BindingMap binding = BindingFactory.create();
> binding.add(expr.asVar(), NodeFactory.createLiteral("foo"));
> SortedDataBag dataBag = BagFactory.newSortedBag(
> new ThresholdPolicyCount<>(0),
> SerializationFactoryFinder.bindingSerializationFactory(),
> new BindingComparator(new ArrayList<>()));
> try {
> dataBag.add(binding);
> dataBag.flush();
> // Spill file looks like the following:
> // VARS ?/1 .
> // "foo" .
> Binding actual = dataBag.iterator().next();
> assertEquals(binding, actual);
> } finally {
> dataBag.close();
> }
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] jena pull request #398: JENA-1523: Allow internal variables names in variabl...

[afs]

GitHub user afs opened a pull request:

https://github.com/apache/jena/pull/398

JENA-1523: Allow internal variables names in variable parsing.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/afs/jena var-databag

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/jena/pull/398.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #398


commit 6a9ad3401cb3cf3326489adc2be4d89d2dc40b8e
Author: Andy Seaborne 
Date:   2018-04-13T16:53:48Z

JENA-1523: Allow internal variables names in variable parsing.




---

[jira] [Commented] (JENA-1523) "VARS requires a list of variables" exception w/spilling and renamed vars

[Andy Seaborne (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437505#comment-16437505
 ] 

Andy Seaborne commented on JENA-1523:
-

Thanks for a clear and reproduceable report!

> "VARS requires a list of variables" exception w/spilling and renamed vars
> -
>
> Key: JENA-1523
> URL: https://issues.apache.org/jira/browse/JENA-1523
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.7.0
>Reporter: Shawn Smith
>Priority: Major
>
> Spilling a {{DistinctDataBag}} or {{SortedDataBag}} when executing SPARQL 
> queries that are modified by {{TransformScopeRename}} can result in the 
> following:
> {noformat}
> org.apache.jena.riot.RiotException: [line: 1, col: 7 ] VARS requires a list 
> of variables (found '[SLASH]')
> at 
> org.apache.jena.riot.system.ErrorHandlerFactory$ErrorHandlerStd.fatal(ErrorHandlerFactory.java:147)
> at org.apache.jena.riot.lang.LangEngine.raiseException(LangEngine.java:148)
> at org.apache.jena.riot.lang.LangEngine.exceptionDirect(LangEngine.java:143)
> at org.apache.jena.riot.lang.LangEngine.exception(LangEngine.java:137)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream.access$1900(BindingInputStream.java:64)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream$IteratorTuples.directiveVars(BindingInputStream.java:227)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream$IteratorTuples.directives(BindingInputStream.java:140)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream$IteratorTuples.(BindingInputStream.java:129)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream.(BindingInputStream.java:99)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream.(BindingInputStream.java:78)
> at 
> org.apache.jena.sparql.engine.binding.BindingInputStream.(BindingInputStream.java:73)
> at 
> org.apache.jena.riot.system.SerializationFactoryFinder$1.createDeserializer(SerializationFactoryFinder.java:56)
> at 
> org.apache.jena.atlas.data.SortedDataBag.getInputIterator(SortedDataBag.java:190)
> at org.apache.jena.atlas.data.SortedDataBag.iterator(SortedDataBag.java:235)
> at org.apache.jena.atlas.data.SortedDataBag.iterator(SortedDataBag.java:206)
> at 
> org.apache.jena.atlas.data.DistinctDataBag.iterator(DistinctDataBag.java:94){noformat}
> The problem is that renaming variables prepends a "/" so that, for example, 
> the first line of the spill file might look like the following which 
> {{BindingInputStream.directiveVars()}} can't parse:
> {noformat}
> VARS ?/.1 ?/.0 ?v_2 ?v_21 ?v_1 .{noformat}
> Here's a test case that reproduces the exception:
> {noformat}
> @Test
> public void testWithRenamedVars() {
> ExprVar expr = (ExprVar) Rename.renameVars(new ExprVar("1"), 
> Collections.emptySet());
> BindingMap binding = BindingFactory.create();
> binding.add(expr.asVar(), NodeFactory.createLiteral("foo"));
> SortedDataBag dataBag = BagFactory.newSortedBag(
> new ThresholdPolicyCount<>(0),
> SerializationFactoryFinder.bindingSerializationFactory(),
> new BindingComparator(new ArrayList<>()));
> try {
> dataBag.add(binding);
> dataBag.flush();
> // Spill file looks like the following:
> // VARS ?/1 .
> // "foo" .
> Binding actual = dataBag.iterator().next();
> assertEquals(binding, actual);
> } finally {
> dataBag.close();
> }
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Old tickets.

[ajs6f]

> Yet open tickets do in some ways suggest they may happen sometime which isn't 
> the case.

Agree 100%.

I'm pretty happy closing tickets with a status that indicates just what you are 
saying; "This is so old that we can no longer effectively work it. If you 
disagree, please open a new up-to-date ticket. " Maybe we can have a closed 
ticket status like "OBSOLETE" or something like that?

Adam

> On Apr 13, 2018, at 11:58 AM, Andy Seaborne  wrote:
> 
> The number of unresolved tickets has climbed a bit recently so I cheated and 
> went and cleaned up some old ones to keep the count down.  The batch today 
> were over 4 years old (arbitrary choice) and look to be done, superseded or 
> in some way no longer relevant.
> 
> I thought they were all clear-cut but do reopen them if you see ticket 
> differently.
> 
> Generally, what to do about old tickets?
> 
> Some are still relevant, some are addressed elsewhere, some have drifted to 
> the point of being difficult to understand.  Where an old ticket that isn't 
> getting any interest (there are at least 5 SDB tickets), I don't see that 
> having it open serves much purpose; it isn't a promise to do anything about 
> it. If new information comes along, it is likely in a new ticket. Yet open 
> tickets do in some ways suggest they may happen sometime which isn't the case.
> 
> Thoughts?
> 
>Andy
> 

Old tickets.

[Andy Seaborne]

The number of unresolved tickets has climbed a bit recently so I cheated 
and went and cleaned up some old ones to keep the count down.  The batch 
today were over 4 years old (arbitrary choice) and look to be done, 
superseded or in some way no longer relevant.


I thought they were all clear-cut but do reopen them if you see ticket 
differently.


Generally, what to do about old tickets?

Some are still relevant, some are addressed elsewhere, some have drifted 
to the point of being difficult to understand.  Where an old ticket that 
isn't getting any interest (there are at least 5 SDB tickets), I don't 
see that having it open serves much purpose; it isn't a promise to do 
anything about it. If new information comes along, it is likely in a new 
ticket. Yet open tickets do in some ways suggest they may happen 
sometime which isn't the case.


Thoughts?

Andy

[jira] [Commented] (JENA-259) Add TDB classes to assembler defaults

[Andy Seaborne (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437383#comment-16437383
 ] 

Andy Seaborne commented on JENA-259:


Happens as part of JENA-1029.

> Add TDB classes to assembler defaults
> -
>
> Key: JENA-259
> URL: https://issues.apache.org/jira/browse/JENA-259
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Jena
>Reporter: Ian Dickinson
>Priority: Minor
> Fix For: Jena 3.0.1
>
>
> Now that TDB is shipped as part of the Jena single download, it would be nice 
> if Assemblers would recognize TDB functionality by default. At present, it's 
> necessary to use the loadClass extension mechanism as described on
> http://jena.apache.org/documentation/tdb/assembler.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (JENA-259) Add TDB classes to assembler defaults

[Andy Seaborne (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne closed JENA-259.
--
   Resolution: Fixed
Fix Version/s: Jena 3.0.1

> Add TDB classes to assembler defaults
> -
>
> Key: JENA-259
> URL: https://issues.apache.org/jira/browse/JENA-259
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Jena
>Reporter: Ian Dickinson
>Priority: Minor
> Fix For: Jena 3.0.1
>
>
> Now that TDB is shipped as part of the Jena single download, it would be nice 
> if Assemblers would recognize TDB functionality by default. At present, it's 
> necessary to use the loadClass extension mechanism as described on
> http://jena.apache.org/documentation/tdb/assembler.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (JENA-408) SDB should not attempt to execute multiple update statements in one jdbc statement

[Andy Seaborne (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne closed JENA-408.
--
Resolution: Won't Fix

SDB is legacy.

As noted the fix is harsh, and can split legal single SQL statements.

> SDB should not attempt to execute multiple update statements in one jdbc 
> statement
> --
>
> Key: JENA-408
> URL: https://issues.apache.org/jira/browse/JENA-408
> Project: Apache Jena
>  Issue Type: Bug
>  Components: SDB
>Affects Versions: SDB 1.3.6
>Reporter: Simon Helsen
>Priority: Minor
> Attachments: patch.txt
>
>
> Some of the db providers (I noticed in db2, but there may be others) attempt 
> to execute update statements by separating them with a semi-colon. This is 
> not supported by the jdbc spec and most jdbc drivers won't be able to handle 
> this correctly. 
> I am not entirely sure why such statements are present in SDB but I suspect 
> that old jdbc 3 drivers for db2 permitted this. The fix is relatively simple 
> and a patch is being attached



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (JENA-485) TDB should provide a way to flush journalled data back to the DB.

[Andy Seaborne (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne closed JENA-485.
--
   Resolution: Done
 Assignee: Andy Seaborne
Fix Version/s: Jena 3.1.1

Done over a few TDB1 enhancements including JENA-1209.


> TDB should provide a way to flush journalled data back to the DB.
> -
>
> Key: JENA-485
> URL: https://issues.apache.org/jira/browse/JENA-485
> Project: Apache Jena
>  Issue Type: Bug
>  Components: TDB
>Affects Versions: Jena 2.10.1
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.1.1
>
>
> TDB batches write-commits for performance reasons.  Commits are safe when 
> they are flushed to the journal.  At some point, the journal is written back 
> to the main database.  This happens periodically in use and always happens on 
> startup.
> It would be convenient to allow application code to cleanly force writing the 
> journal back to the database for the case when the application has been 
> preparing a database for moving elsewhere.  It is not critical the journal is 
> flushed (its safe anyway) but it is neater for preparing databases for moving 
> to a server for publication).
> Workaround 1 : Set the TransactionManager.QueueBatchSize to zero to make each 
> write-commit attempt to flush the journal.  It may not be able to due to 
> outstanding read transactions.
> Workaround 2 : run any TDB command line tool on the database e.g. 
> {noformat}
> tdbquery --loc=DIR 'ASK{}'
> {noformat}
> as this will open the database and so flush the journal).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (JENA-485) TDB should provide a way to flush journalled data back to the DB.

[Andy Seaborne (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437372#comment-16437372
 ] 

Andy Seaborne edited comment on JENA-485 at 4/13/18 2:38 PM:
-

This is possible with {{StoreConnection.flush}} which calls 
{{TransactionManager.flush}}.

It can be forced by going into exclusive mode to ensure the database is 
currently updateable.


was (Author: andy.seaborne):
This is possible with {{StoreConnection.flush}] which calls 
{{TransactionManager.flush}}.

It can be forced by going into exclusive mode to ensure the database is 
currently updateable.

> TDB should provide a way to flush journalled data back to the DB.
> -
>
> Key: JENA-485
> URL: https://issues.apache.org/jira/browse/JENA-485
> Project: Apache Jena
>  Issue Type: Bug
>  Components: TDB
>Affects Versions: Jena 2.10.1
>Reporter: Andy Seaborne
>Priority: Minor
>
> TDB batches write-commits for performance reasons.  Commits are safe when 
> they are flushed to the journal.  At some point, the journal is written back 
> to the main database.  This happens periodically in use and always happens on 
> startup.
> It would be convenient to allow application code to cleanly force writing the 
> journal back to the database for the case when the application has been 
> preparing a database for moving elsewhere.  It is not critical the journal is 
> flushed (its safe anyway) but it is neater for preparing databases for moving 
> to a server for publication).
> Workaround 1 : Set the TransactionManager.QueueBatchSize to zero to make each 
> write-commit attempt to flush the journal.  It may not be able to due to 
> outstanding read transactions.
> Workaround 2 : run any TDB command line tool on the database e.g. 
> {noformat}
> tdbquery --loc=DIR 'ASK{}'
> {noformat}
> as this will open the database and so flush the journal).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-485) TDB should provide a way to flush journalled data back to the DB.

[Andy Seaborne (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437372#comment-16437372
 ] 

Andy Seaborne commented on JENA-485:


This is possible with {{StoreConnection.flush}] which calls 
{{TransactionManager.flush}}.

It can be forced by going into exclusive mode to ensure the database is 
currently updateable.

> TDB should provide a way to flush journalled data back to the DB.
> -
>
> Key: JENA-485
> URL: https://issues.apache.org/jira/browse/JENA-485
> Project: Apache Jena
>  Issue Type: Bug
>  Components: TDB
>Affects Versions: Jena 2.10.1
>Reporter: Andy Seaborne
>Priority: Minor
>
> TDB batches write-commits for performance reasons.  Commits are safe when 
> they are flushed to the journal.  At some point, the journal is written back 
> to the main database.  This happens periodically in use and always happens on 
> startup.
> It would be convenient to allow application code to cleanly force writing the 
> journal back to the database for the case when the application has been 
> preparing a database for moving elsewhere.  It is not critical the journal is 
> flushed (its safe anyway) but it is neater for preparing databases for moving 
> to a server for publication).
> Workaround 1 : Set the TransactionManager.QueueBatchSize to zero to make each 
> write-commit attempt to flush the journal.  It may not be able to due to 
> outstanding read transactions.
> Workaround 2 : run any TDB command line tool on the database e.g. 
> {noformat}
> tdbquery --loc=DIR 'ASK{}'
> {noformat}
> as this will open the database and so flush the journal).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (JENA-530) Transactions (model and dataset) need to propagate through wrappers such as inference graphs.

[Andy Seaborne (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne closed JENA-530.
--
   Resolution: Duplicate
Fix Version/s: Jena 3.7.0

> Transactions (model and dataset) need to propagate through wrappers such as 
> inference graphs.
> -
>
> Key: JENA-530
> URL: https://issues.apache.org/jira/browse/JENA-530
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 2.10.1
>Reporter: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.7.0
>
>
> Complicated stacks of functionality do not propagate transactions.  A common 
> case is where the wrappers add functionality but do not add additional 
> persistent state.  In such cases, transactions can be passed to the base 
> storage.  An example of this is the inference graphs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1519) OpWalkerVisitor should interact better with custom operators

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437366#comment-16437366
 ] 

ASF GitHub Bot commented on JENA-1519:
--

Github user jeremy-coulon commented on a diff in the pull request:

https://github.com/apache/jena/pull/394#discussion_r181407237
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/sparql/algebra/OpWalker.java ---
@@ -139,6 +139,7 @@ protected void visitN(OpN op) {
 @Override
 protected void visitExt(OpExt op) {
 before(op) ;
+super.visitExt(op);
--- End diff --

Visiting the real OpExt is not useful for me but I can't say for other 
people.


> OpWalkerVisitor should interact better with custom operators
> 
>
> Key: JENA-1519
> URL: https://issues.apache.org/jira/browse/JENA-1519
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.6.0
>Reporter: Jeremy Coulon
>Priority: Major
>
> When visiting an OpExt, current implementation of OpWalkerVisitor is just 
> calling the visitor on opExt.effectiveOp().
> However if OpExt is replacing a sub-tree of the algebra instead of a single 
> leaf node, the sub-tree is ignored by walker.
> I found this bug when trying to execute a query with a MINUS operator with 
> either side of the operator being replaced by an custom operator.
> For example the following query is not working, if I transform both side of 
> MINUS with a custom operator:
> {{(project (?animal)}}
> {{  (minus}}
> {{    (bgp (triple ?animal rdf:type ex:Animal))}}
> {{    (filter (|| (= ?type ex:Reptile) (= ?type ex:Insect))}}
> {{      (bgp (triple ?animal rdf:type ?type)}}
> which I transform into:
> {{(project (?animal)}}
> {{  (minus}}
> {{    (op-ext )}}
> {{    (op-ext )))}}
> The reason is that MINUS is calling OpVars.visibleVars() which does not walk 
> into the subop of the filter.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] jena pull request #394: JENA-1519: OpWalkerVisitor with custom operators

[jeremy-coulon]

Github user jeremy-coulon commented on a diff in the pull request:

https://github.com/apache/jena/pull/394#discussion_r181407237
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/sparql/algebra/OpWalker.java ---
@@ -139,6 +139,7 @@ protected void visitN(OpN op) {
 @Override
 protected void visitExt(OpExt op) {
 before(op) ;
+super.visitExt(op);
--- End diff --

Visiting the real OpExt is not useful for me but I can't say for other 
people.


---

[jira] [Commented] (JENA-555) Deprecate StageGenerators prior to removal.

[Andy Seaborne (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437363#comment-16437363
 ] 

Andy Seaborne commented on JENA-555:


{{StageGenerator}}s will exist due to the custom graph in general datasets case 
and it is hard to see a better way to treat that situation. Closing the ticket.


> Deprecate StageGenerators prior to removal.
> ---
>
> Key: JENA-555
> URL: https://issues.apache.org/jira/browse/JENA-555
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
>
> StageGenerators are an old way of extending SPARQL query execution.  It is 
> better to extend OpExecutor (the general purpose algebra execution engine).  
> OpExecutor calls the generic StageGenerator currently.
> # Remove StageGenerator from documentation on extending ARQ.
> # Extract the BGP execution into a library.
> # OpExecutor to directly call this library unless the context option is set.
> # Don't set the global context(key = ARQ.stageGenerator) with a 
> StageGenerator.
> # Mark StageGenerator \@Deprecated
> # Update examples
> # Check TDB and SDB, esp TDB on single graphs.
> Important here is how a graph from one of those storage subsystems, when 
> places in general purpose dataset with other graph types, still manages to go 
> to the storage specific BGP execution. (Maybe this does not matter - if it 
> misses it will fall back to using {{find()}} so always be correct.)
> We may been to retain the idea of a StageGenerator to catch the single-graph 
> case but at least remove as a general extension point in favour of OpExecutor.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (JENA-555) Deprecate StageGenerators prior to removal.

[Andy Seaborne (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne closed JENA-555.
--
Resolution: Won't Fix

> Deprecate StageGenerators prior to removal.
> ---
>
> Key: JENA-555
> URL: https://issues.apache.org/jira/browse/JENA-555
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
>
> StageGenerators are an old way of extending SPARQL query execution.  It is 
> better to extend OpExecutor (the general purpose algebra execution engine).  
> OpExecutor calls the generic StageGenerator currently.
> # Remove StageGenerator from documentation on extending ARQ.
> # Extract the BGP execution into a library.
> # OpExecutor to directly call this library unless the context option is set.
> # Don't set the global context(key = ARQ.stageGenerator) with a 
> StageGenerator.
> # Mark StageGenerator \@Deprecated
> # Update examples
> # Check TDB and SDB, esp TDB on single graphs.
> Important here is how a graph from one of those storage subsystems, when 
> places in general purpose dataset with other graph types, still manages to go 
> to the storage specific BGP execution. (Maybe this does not matter - if it 
> misses it will fall back to using {{find()}} so always be correct.)
> We may been to retain the idea of a StageGenerator to catch the single-graph 
> case but at least remove as a general extension point in favour of OpExecutor.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (JENA-571) GraphTDB fails to implements .close() but fails to pass this up to GraphBase.

[Andy Seaborne (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne closed JENA-571.
--
Resolution: Fixed

> GraphTDB fails to implements .close() but fails to pass this up to GraphBase.
> -
>
> Key: JENA-571
> URL: https://issues.apache.org/jira/browse/JENA-571
> Project: Apache Jena
>  Issue Type: Bug
>  Components: TDB
>Affects Versions: TDB 1.0.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 2.11.1
>
>
> from:
> http://mail-archives.apache.org/mod_mbox/jena-dev/201310.mbox/%3CCALvhUEWRutgUOMqKpFaqK38Lr5ZKhUpAhoYVDEvMarEKaWtPKQ%40mail.gmail.com%3E



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-571) GraphTDB fails to implements .close() but fails to pass this up to GraphBase.

[Andy Seaborne (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437362#comment-16437362
 ] 

Andy Seaborne commented on JENA-571:


This was fixed sometime ago.  The graphs are no longer cached and they also 
work across transaction boundaries.


> GraphTDB fails to implements .close() but fails to pass this up to GraphBase.
> -
>
> Key: JENA-571
> URL: https://issues.apache.org/jira/browse/JENA-571
> Project: Apache Jena
>  Issue Type: Bug
>  Components: TDB
>Affects Versions: TDB 1.0.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 2.11.1
>
>
> from:
> http://mail-archives.apache.org/mod_mbox/jena-dev/201310.mbox/%3CCALvhUEWRutgUOMqKpFaqK38Lr5ZKhUpAhoYVDEvMarEKaWtPKQ%40mail.gmail.com%3E



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1514) Class cast exception with BigInteger literals.

[Claude Warren (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437361#comment-16437361
 ] 

Claude Warren commented on JENA-1514:
-

We may have to put this on the queue for Jena 4.  But I am ok with putting
it back until we can figure out how to solve the problem.

On Fri, Apr 13, 2018 at 3:19 PM, Andy Seaborne (JIRA) 




-- 
I like: Like Like - The likeliest place on the web

LinkedIn: http://www.linkedin.com/in/claudewarren


> Class cast exception with BigInteger literals.
> --
>
> Key: JENA-1514
> URL: https://issues.apache.org/jira/browse/JENA-1514
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Jena
>Affects Versions: Jena 3.6.0, Jena 3.7.0
>Reporter: Claude Warren
>Priority: Minor
> Attachments: BigIntIssue.java
>
>
> When saving a BigInteger as a literal it is converted into an 
> XSDBaseNumericType.
> When that  type is read back it is converted into the smallest numeric data 
> type that can hold the value; a narrowing if you will.
> While  this works fine for primitive and primitive wrapping types (e.g. int 
> and Integer) there is no automatic boxing available for BigInteger so 
> attempting to retrieve the value of a BigInteger that is smaller than the 
> Long.MAX_VALUE will result in a class cast exception when the primitive type 
> is cast to the BigInteger.
> I suspect the similar issues arise when BigDecimal is also used but I have 
> not tested.
> Should we address this issue by creating a BigInteger and BigDecimal type 
> that perhaps extends XSDBaseNumericType?  Should we address this issue at all 
> and just post a warning?
> Test code is included to show the issue.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (JENA-594) rdfcat silently ignores - as stdin if input type isn't specified

[Andy Seaborne (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne closed JENA-594.
--
Resolution: Won't Fix

> rdfcat silently ignores - as stdin if input type isn't specified
> 
>
> Key: JENA-594
> URL: https://issues.apache.org/jira/browse/JENA-594
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Cmd line tools
>Affects Versions: Jena 2.11.0
>Reporter: Joshua Taylor
>Assignee: Andy Seaborne
>Priority: Minor
>  Labels: rdfcat, riot
> Fix For: Jena 2.13.0
>
>
> Treatment of content from standard in by - and /dev/stdin differs when format 
> is not specified.
> Using -, non RDF/XML content is silently ignored.  Specifying -n gets it 
> treated correctly.
> {noformat}
> $ echo '  ' | rdfcat -
>  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#;>
> 
> $ echo '  ' | rdfcat -n -
>  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#;
> xmlns:j.0="file:///home/taylorj/tmp/">
>   
> 
>   
> 
> {noformat}
> -n with /dev/stdin works, too.  Using /dev/stdin with no format option blows 
> up, though.  (It's not silently ignored like - was)
> {noformat}
> $ echo '  ' | rdfcat -n /dev/stdin 
>  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#;
> xmlns:j.0="file:///dev/">
>   
> 
>   
> 
> $ echo '  ' | rdfcat /dev/stdin 
> 11:46:21 WARN  riot :: {W104} Unqualified typed nodes are not 
> allowed. Type treated as a relative URI.
> 11:46:21 WARN  riot :: {W136} Relative URIs are not permitted 
> in RDF: specifically 
> 11:46:21 WARN  riot :: {W104} Unqualified property elements 
> are not allowed. Treated as a relative URI.
> 11:46:21 WARN  riot :: {W136} Relative URIs are not permitted 
> in RDF: specifically 
> 11:46:21 WARN  riot :: {W104} Unqualified typed nodes are not 
> allowed. Type treated as a relative URI.
> 11:46:21 WARN  riot :: {W136} Relative URIs are not permitted 
> in RDF: specifically 
> 11:46:21 ERROR riot :: XML document structures must start and 
> end within the same entity.
> Exception in thread "main" org.apache.jena.riot.RiotException: XML document 
> structures must start and end within the same entity.
> at 
> org.apache.jena.riot.system.ErrorHandlerFactory$ErrorHandlerStd.fatal(ErrorHandlerFactory.java:136)
> …
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-594) rdfcat silently ignores - as stdin if input type isn't specified

[Andy Seaborne (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437359#comment-16437359
 ] 

Andy Seaborne commented on JENA-594:


rdfcat is retired and replaced by "riot".  

rdfcat now says

{noformat}
--
   DEPRECATED: Please use 'riot' instead.
 http://jena.apache.org/documentation/io/#command-line-tools
--
{noformat}

so closing this but please do reopen with new information.

> rdfcat silently ignores - as stdin if input type isn't specified
> 
>
> Key: JENA-594
> URL: https://issues.apache.org/jira/browse/JENA-594
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Cmd line tools
>Affects Versions: Jena 2.11.0
>Reporter: Joshua Taylor
>Assignee: Andy Seaborne
>Priority: Minor
>  Labels: rdfcat, riot
> Fix For: Jena 2.13.0
>
>
> Treatment of content from standard in by - and /dev/stdin differs when format 
> is not specified.
> Using -, non RDF/XML content is silently ignored.  Specifying -n gets it 
> treated correctly.
> {noformat}
> $ echo '  ' | rdfcat -
>  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#;>
> 
> $ echo '  ' | rdfcat -n -
>  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#;
> xmlns:j.0="file:///home/taylorj/tmp/">
>   
> 
>   
> 
> {noformat}
> -n with /dev/stdin works, too.  Using /dev/stdin with no format option blows 
> up, though.  (It's not silently ignored like - was)
> {noformat}
> $ echo '  ' | rdfcat -n /dev/stdin 
>  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#;
> xmlns:j.0="file:///dev/">
>   
> 
>   
> 
> $ echo '  ' | rdfcat /dev/stdin 
> 11:46:21 WARN  riot :: {W104} Unqualified typed nodes are not 
> allowed. Type treated as a relative URI.
> 11:46:21 WARN  riot :: {W136} Relative URIs are not permitted 
> in RDF: specifically 
> 11:46:21 WARN  riot :: {W104} Unqualified property elements 
> are not allowed. Treated as a relative URI.
> 11:46:21 WARN  riot :: {W136} Relative URIs are not permitted 
> in RDF: specifically 
> 11:46:21 WARN  riot :: {W104} Unqualified typed nodes are not 
> allowed. Type treated as a relative URI.
> 11:46:21 WARN  riot :: {W136} Relative URIs are not permitted 
> in RDF: specifically 
> 11:46:21 ERROR riot :: XML document structures must start and 
> end within the same entity.
> Exception in thread "main" org.apache.jena.riot.RiotException: XML document 
> structures must start and end within the same entity.
> at 
> org.apache.jena.riot.system.ErrorHandlerFactory$ErrorHandlerStd.fatal(ErrorHandlerFactory.java:136)
> …
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-703) TDB - Ensure readers don't block writeback forever.

[Andy Seaborne (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437354#comment-16437354
 ] 

Andy Seaborne commented on JENA-703:


This situation does not occur in in TDB2 because write transactions commit as 
they exit and the write updates the main database.

While this is a more expensive scheme, it doesn't have the same issue as this 
ticket.

[~kbkreddy] - is there code from your experiment in 2014?

 

> TDB - Ensure readers don't block writeback forever.
> ---
>
> Key: JENA-703
> URL: https://issues.apache.org/jira/browse/JENA-703
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: TDB
>Affects Versions: Jena 2.11.1
>Reporter: Andy Seaborne
>Priority: Major
>
> The commit queue can only be flushed when the main storage is quiet.  A 
> stream of readers can lead to the main storage never being quiet.
> One possibility is to place a maximum (quite high) on the number of readers 
> allowed after the decision to flush the journal to main storage. If exceeded, 
>  then lock readers for a while, flush and resume.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1514) Class cast exception with BigInteger literals.

[Andy Seaborne (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437352#comment-16437352
 ] 

Andy Seaborne commented on JENA-1514:
-

I can't see a way of doing anything here that is not a change that will impact 
applications.

The contracts around XSDBaseNumericType.cannonicalise which impact memory graph 
indexing, also look to be such that a change will affect behaviour there as 
well.

Can we close this until a concrete proposal is available when we can explore 
the impact on a concrete case?

> Class cast exception with BigInteger literals.
> --
>
> Key: JENA-1514
> URL: https://issues.apache.org/jira/browse/JENA-1514
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Jena
>Affects Versions: Jena 3.6.0, Jena 3.7.0
>Reporter: Claude Warren
>Priority: Minor
> Attachments: BigIntIssue.java
>
>
> When saving a BigInteger as a literal it is converted into an 
> XSDBaseNumericType.
> When that  type is read back it is converted into the smallest numeric data 
> type that can hold the value; a narrowing if you will.
> While  this works fine for primitive and primitive wrapping types (e.g. int 
> and Integer) there is no automatic boxing available for BigInteger so 
> attempting to retrieve the value of a BigInteger that is smaller than the 
> Long.MAX_VALUE will result in a class cast exception when the primitive type 
> is cast to the BigInteger.
> I suspect the similar issues arise when BigDecimal is also used but I have 
> not tested.
> Should we address this issue by creating a BigInteger and BigDecimal type 
> that perhaps extends XSDBaseNumericType?  Should we address this issue at all 
> and just post a warning?
> Test code is included to show the issue.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1488) SelectiveFoldingFilter for jena-text

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437350#comment-16437350
 ] 

ASF GitHub Bot commented on JENA-1488:
--

Github user osma commented on the issue:

https://github.com/apache/jena/pull/395
  
I tested this locally and it seems to work as it should. Great work!


> SelectiveFoldingFilter for jena-text
> 
>
> Key: JENA-1488
> URL: https://issues.apache.org/jira/browse/JENA-1488
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Text
>Affects Versions: Jena 3.6.0
>Reporter: Osma Suominen
>Assignee: Bruno P. Kinoshita
>Priority: Major
>
> Currently there's some support for accent folding in jena-text, because 
> Lucene provides an ASCIIFoldingFilter. When this filter is enabled, a search 
> for "deja vu" will match the literal "déjà vu" in the data.
> But we can't use it here at the National Library of Finland (for Finto.fi / 
> Skosmos), because it folds too much! In the Finnish alphabet, in addition to 
> the Latin a-z (which are in ASCII) we use the letters åäö and these should 
> not be folded to ASCII. So we need a Lucene analyzer that can be configured 
> with an exclude list, something like 
>  
> new SelectiveFoldingFilter(String excludeChars) 
>  
> and that can be also be configured via the Jena assembler just like other 
> analyzers supported by jena-text. 
>  
> This was also briefly discussed on the skosmos-users mailing list: 
> [https://groups.google.com/d/msg/skosmos-users/x3zR_uRBQT0/Q90-O_iDAQAJ] 
> Apparently Norwegians have the same problem...
> I've discussed this with [~kinow] and he has some initial code to implement 
> this feature, so I think we can turn this into a PR fairly soon.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] jena issue #395: JENA-1488: add a selective folding analyzer

[osma]

Github user osma commented on the issue:

https://github.com/apache/jena/pull/395
  
I tested this locally and it seems to work as it should. Great work!


---

[jira] [Resolved] (JENA-1517) Some queries not working when using OpQuadBlock

[Andy Seaborne (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-1517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne resolved JENA-1517.
-
   Resolution: Fixed
Fix Version/s: Jena 3.8.0

> Some queries not working when using OpQuadBlock
> ---
>
> Key: JENA-1517
> URL: https://issues.apache.org/jira/browse/JENA-1517
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.6.0
>Reporter: Jeremy Coulon
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.8.0
>
>
> I am using a custom QueryEngine that rewrites algebra. I am transforming 
> OpBGP into OpQuadBlock (not OpQuadPattern).
> Most queries work fine except when using one of the following:
>  * MINUS
>  * FILTER EXISTS
>  * FILTER NOT EXISTS
> I tracked the issue down to this visitor: 
> org.apache.jena.sparql.algebra.OpVarsPattern.
> An override for visit(OpQuadBlock) is missing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (JENA-1517) Some queries not working when using OpQuadBlock

[Andy Seaborne (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-1517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne reassigned JENA-1517:
---

Assignee: Andy Seaborne

> Some queries not working when using OpQuadBlock
> ---
>
> Key: JENA-1517
> URL: https://issues.apache.org/jira/browse/JENA-1517
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.6.0
>Reporter: Jeremy Coulon
>Assignee: Andy Seaborne
>Priority: Major
>
> I am using a custom QueryEngine that rewrites algebra. I am transforming 
> OpBGP into OpQuadBlock (not OpQuadPattern).
> Most queries work fine except when using one of the following:
>  * MINUS
>  * FILTER EXISTS
>  * FILTER NOT EXISTS
> I tracked the issue down to this visitor: 
> org.apache.jena.sparql.algebra.OpVarsPattern.
> An override for visit(OpQuadBlock) is missing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1517) Some queries not working when using OpQuadBlock

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437334#comment-16437334
 ] 

ASF subversion and git services commented on JENA-1517:
---

Commit db818ea3f70e15b9b0c9cd9bec0e16c6fa9ae6e6 in jena's branch 
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=db818ea ]

JENA-1517: Merge commit 'refs/pull/393/head' of https://github.com/apache/jena

This closes #393.


> Some queries not working when using OpQuadBlock
> ---
>
> Key: JENA-1517
> URL: https://issues.apache.org/jira/browse/JENA-1517
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.6.0
>Reporter: Jeremy Coulon
>Priority: Major
>
> I am using a custom QueryEngine that rewrites algebra. I am transforming 
> OpBGP into OpQuadBlock (not OpQuadPattern).
> Most queries work fine except when using one of the following:
>  * MINUS
>  * FILTER EXISTS
>  * FILTER NOT EXISTS
> I tracked the issue down to this visitor: 
> org.apache.jena.sparql.algebra.OpVarsPattern.
> An override for visit(OpQuadBlock) is missing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1517) Some queries not working when using OpQuadBlock

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437336#comment-16437336
 ] 

ASF GitHub Bot commented on JENA-1517:
--

Github user asfgit closed the pull request at:

https://github.com/apache/jena/pull/393


> Some queries not working when using OpQuadBlock
> ---
>
> Key: JENA-1517
> URL: https://issues.apache.org/jira/browse/JENA-1517
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.6.0
>Reporter: Jeremy Coulon
>Priority: Major
>
> I am using a custom QueryEngine that rewrites algebra. I am transforming 
> OpBGP into OpQuadBlock (not OpQuadPattern).
> Most queries work fine except when using one of the following:
>  * MINUS
>  * FILTER EXISTS
>  * FILTER NOT EXISTS
> I tracked the issue down to this visitor: 
> org.apache.jena.sparql.algebra.OpVarsPattern.
> An override for visit(OpQuadBlock) is missing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] jena pull request #393: JENA-1517: Implement missing override in OpVarsPatte...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/jena/pull/393


---

[jira] [Commented] (JENA-1519) OpWalkerVisitor should interact better with custom operators

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437326#comment-16437326
 ] 

ASF GitHub Bot commented on JENA-1519:
--

Github user afs commented on a diff in the pull request:

https://github.com/apache/jena/pull/394#discussion_r181393545
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/sparql/algebra/OpWalker.java ---
@@ -139,6 +139,7 @@ protected void visitN(OpN op) {
 @Override
 protected void visitExt(OpExt op) {
 before(op) ;
+super.visitExt(op);
--- End diff --

Not sure about this. It is visiting both the effective op and the real 
OpExt. Shoudn't it be the visitor deciding that? ie. visiting 
`op.effectiveOp()` is required?


> OpWalkerVisitor should interact better with custom operators
> 
>
> Key: JENA-1519
> URL: https://issues.apache.org/jira/browse/JENA-1519
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.6.0
>Reporter: Jeremy Coulon
>Priority: Major
>
> When visiting an OpExt, current implementation of OpWalkerVisitor is just 
> calling the visitor on opExt.effectiveOp().
> However if OpExt is replacing a sub-tree of the algebra instead of a single 
> leaf node, the sub-tree is ignored by walker.
> I found this bug when trying to execute a query with a MINUS operator with 
> either side of the operator being replaced by an custom operator.
> For example the following query is not working, if I transform both side of 
> MINUS with a custom operator:
> {{(project (?animal)}}
> {{  (minus}}
> {{    (bgp (triple ?animal rdf:type ex:Animal))}}
> {{    (filter (|| (= ?type ex:Reptile) (= ?type ex:Insect))}}
> {{      (bgp (triple ?animal rdf:type ?type)}}
> which I transform into:
> {{(project (?animal)}}
> {{  (minus}}
> {{    (op-ext )}}
> {{    (op-ext )))}}
> The reason is that MINUS is calling OpVars.visibleVars() which does not walk 
> into the subop of the filter.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] jena pull request #394: JENA-1519: OpWalkerVisitor with custom operators

[afs]

Github user afs commented on a diff in the pull request:

https://github.com/apache/jena/pull/394#discussion_r181393545
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/sparql/algebra/OpWalker.java ---
@@ -139,6 +139,7 @@ protected void visitN(OpN op) {
 @Override
 protected void visitExt(OpExt op) {
 before(op) ;
+super.visitExt(op);
--- End diff --

Not sure about this. It is visiting both the effective op and the real 
OpExt. Shoudn't it be the visitor deciding that? ie. visiting 
`op.effectiveOp()` is required?


---

[jira] [Commented] (JENA-1521) TDB2 backed Datasets cannot be re-opened.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437319#comment-16437319
 ] 

ASF GitHub Bot commented on JENA-1521:
--

GitHub user afs opened a pull request:

https://github.com/apache/jena/pull/397

TDB2 tidyup

Including JENA-1521 (TDB1 and TDB2 close).

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/afs/jena tdb2-tidyup

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/jena/pull/397.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #397


commit 32608d250fa60788b53db71b79d904fb63dbdd88
Author: Andy Seaborne 
Date:   2018-04-13T12:59:35Z

Add TDB2Factory.assembleDataset. Remove out of date comments.

commit f6d3c77f32e5ba8c48d2b987dea3915004970eab
Author: Andy Seaborne 
Date:   2018-04-13T13:04:55Z

JENA-1521: Don't close. TDB1 and TDB2 datasets are managed differently.

commit 246786abfb60f2908bce52772cd40771ba2a206d
Author: Andy Seaborne 
Date:   2018-04-13T13:05:16Z

Remove deprecated DatasetGraphWithLock.

commit 67b18af43f54814f66f63c13866556b4256e459c
Author: Andy Seaborne 
Date:   2018-04-13T13:31:51Z

JENA-1521: Only really close if non-transactional

commit d65e0ae630911cf1665cbd354d928765d16491ce
Author: Andy Seaborne 
Date:   2018-04-13T13:43:53Z

Remove stray local/




> TDB2 backed Datasets cannot be re-opened.
> -
>
> Key: JENA-1521
> URL: https://issues.apache.org/jira/browse/JENA-1521
> Project: Apache Jena
>  Issue Type: Bug
> Environment: Apache Jena: 3.7.0
> Java: 1.8_162
>Reporter: Greg Albiston
>Priority: Major
>
> If a Dataset connected to with TDB2Factory.connectDataset() is opened, closed 
> and then later re-opened it is reported that the Dataset is closed.
> Opening, closing and re-opening a Dataset with TDBFactory.createDataset() 
> causes no issues.
> Example code to reproduce:
> {noformat}
> public void testTDB2OpenClose() {
> System.out.println("TDB2 Open Close");
>  try {
>  Dataset dataset = TDB2Factory.connectDataset("test_tdb2");
>  dataset.begin(ReadWrite.WRITE);
>  Model defaultModel = dataset.getDefaultModel();
>  
> defaultModel.add(ResourceFactory.createResource("http://example.org/my#SubjA;),
>  ResourceFactory.createProperty("http://example.org/my#PropA;), 
> ResourceFactory.createResource("http://example.org/my#ObjA;));
>  dataset.commit();
>  dataset.end();
>  dataset.close();
> Dataset dataset2 = TDB2Factory.connectDataset("test_tdb2");
>  dataset2.begin(ReadWrite.READ);
>  Model readModel = dataset2.getDefaultModel();
>  Iterator statements = readModel.listStatements();
>  while (statements.hasNext())
> { Statement statement = statements.next(); System.out.println(statement); }
>  dataset2.end();
>  dataset2.close();
>  } catch (Exception ex) \{ System.out.println("Exception: " + 
> ex.getMessage()); }
>  }
>  {noformat}
> {noformat}
>  public void testTDB1OpenClose() {
>  
>  System.out.println("TDB1 Open Close");
>  try {
>  Dataset dataset = TDBFactory.createDataset("test_tdb1");
>  dataset.begin(ReadWrite.WRITE);
>  Model defaultModel = dataset.getDefaultModel();
>  
> defaultModel.add(ResourceFactory.createResource("http://example.org/my#SubjA;),
>  ResourceFactory.createProperty("http://example.org/my#PropA;), 
> ResourceFactory.createResource("http://example.org/my#ObjA;));
>  dataset.commit();
>  dataset.end();
>  dataset.close();
>  
>  Dataset dataset2 = TDBFactory.createDataset("test_tdb1");
>  dataset2.begin(ReadWrite.READ);
>  Model readModel = dataset2.getDefaultModel();
>  Iterator statements = readModel.listStatements();
>  while (statements.hasNext()) \{ Statement statement = statements.next(); 
> System.out.println(statement); }
> dataset2.end();
>  dataset2.close();
>  } catch (Exception ex)
> { System.out.println("Exception: " + ex.getMessage()); }
> }
> {noformat}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] jena pull request #397: TDB2 tidyup

[afs]

GitHub user afs opened a pull request:

https://github.com/apache/jena/pull/397

TDB2 tidyup

Including JENA-1521 (TDB1 and TDB2 close).

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/afs/jena tdb2-tidyup

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/jena/pull/397.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #397


commit 32608d250fa60788b53db71b79d904fb63dbdd88
Author: Andy Seaborne 
Date:   2018-04-13T12:59:35Z

Add TDB2Factory.assembleDataset. Remove out of date comments.

commit f6d3c77f32e5ba8c48d2b987dea3915004970eab
Author: Andy Seaborne 
Date:   2018-04-13T13:04:55Z

JENA-1521: Don't close. TDB1 and TDB2 datasets are managed differently.

commit 246786abfb60f2908bce52772cd40771ba2a206d
Author: Andy Seaborne 
Date:   2018-04-13T13:05:16Z

Remove deprecated DatasetGraphWithLock.

commit 67b18af43f54814f66f63c13866556b4256e459c
Author: Andy Seaborne 
Date:   2018-04-13T13:31:51Z

JENA-1521: Only really close if non-transactional

commit d65e0ae630911cf1665cbd354d928765d16491ce
Author: Andy Seaborne 
Date:   2018-04-13T13:43:53Z

Remove stray local/




---

[jira] [Commented] (JENA-1522) Unable to consistently retrieve data from large dataset

[Brian Mullen (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437287#comment-16437287
 ] 

Brian Mullen commented on JENA-1522:


I'll look into pulling logs.  It'll be tough to find a minimal example, we 
never came across this problem when we were in small scale testing.  Now that 
we have a full set of production data it's starting to come up.  Last backup 
was >25G.

> Unable to consistently retrieve data from large dataset
> ---
>
> Key: JENA-1522
> URL: https://issues.apache.org/jira/browse/JENA-1522
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki, Jena
>Affects Versions: Jena 3.6.0
> Environment: System 1:  Centos 7, Jena 3.6, Unknown Fuseki version.
> System 2:  Ubuntu 16.04 running Docker.  Running stain/jena-fuseki from the 
> official Docker Hub.
>  
>Reporter: Brian Mullen
>Priority: Critical
>
> In my 500M+ triple dataset, queries seem to be failing for no clear reason. 
> Here's an example.
> {code:java}
> prefix Products:  
> select ?p ?o 
> where { 
> Products:ABC ?p ?o . 
> }
> {code}
> ...results in a list like:
> {code:java}
> Products:HasComponent Products:DEF 
> Products:HasComponent Products:GHI {code}
> Now running this query:
> {code:java}
> prefix Products:  
> select ?p 
> where { 
> Products:ABC ?p Products:DEF . 
> } {code}
> ...has no results. How is this possible?
>  
> Here's another example.
> {code:java}
> prefix Products:  
> ask where { 
> Products:ABC Products:PartNumber ?p . 
> filter ( ?p = "ABC" ) 
> } {code}
> This returns "True"
>  
> {code:java}
> prefix Products:  
> ask where { 
> ?s Products:PartNumber ?p . 
> filter ( ?p = "ABC" ) 
> } {code}
> This returns "False"
>  
> What other info can I provide?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1522) Unable to consistently retrieve data from large dataset

[Andy Seaborne (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437282#comment-16437282
 ] 

Andy Seaborne commented on JENA-1522:
-

Hi Brian,

I don't see anything wrong in the description. It would need a complete, 
minimal example.

Is there anything in the Fuseki log file?

What is the history of the dataset? (is it an old database used with other 
version?or a fresh one?)

Have you tried dumping it and reloading to create a new, fresh database?

 

 

 

> Unable to consistently retrieve data from large dataset
> ---
>
> Key: JENA-1522
> URL: https://issues.apache.org/jira/browse/JENA-1522
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki, Jena
>Affects Versions: Jena 3.6.0
> Environment: System 1:  Centos 7, Jena 3.6, Unknown Fuseki version.
> System 2:  Ubuntu 16.04 running Docker.  Running stain/jena-fuseki from the 
> official Docker Hub.
>  
>Reporter: Brian Mullen
>Priority: Critical
>
> In my 500M+ triple dataset, queries seem to be failing for no clear reason. 
> Here's an example.
> {code:java}
> prefix Products:  
> select ?p ?o 
> where { 
> Products:ABC ?p ?o . 
> }
> {code}
> ...results in a list like:
> {code:java}
> Products:HasComponent Products:DEF 
> Products:HasComponent Products:GHI {code}
> Now running this query:
> {code:java}
> prefix Products:  
> select ?p 
> where { 
> Products:ABC ?p Products:DEF . 
> } {code}
> ...has no results. How is this possible?
>  
> Here's another example.
> {code:java}
> prefix Products:  
> ask where { 
> Products:ABC Products:PartNumber ?p . 
> filter ( ?p = "ABC" ) 
> } {code}
> This returns "True"
>  
> {code:java}
> prefix Products:  
> ask where { 
> ?s Products:PartNumber ?p . 
> filter ( ?p = "ABC" ) 
> } {code}
> This returns "False"
>  
> What other info can I provide?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1521) TDB2 backed Datasets cannot be re-opened.

[Andy Seaborne (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437263#comment-16437263
 ] 

Andy Seaborne commented on JENA-1521:
-

Datasets shouldn't be closed at the end of a transaction. Close, it does does 
anything, means "not to be used again".

This is why the name was changed to {{TDB2Factory.connectDataset}} from 
{{createDataset}} to get away from the idea of create-destroy.

Because TDB1 and TDB2 databases are held JVM wide, calling the factory again 
gets the same database.

TDB1 ({{DatasetGraphTransaction}}) happens to do very little on {{close()}} and 
does not pass it down further. What clearup it does is reversed, by luck, on 
reuse.

TDB2 ({{DatasetGraphSwitchable}} passes it on to the storage and marks it 
closed.

We could ignore it in TDB2 and properly ignore it in TDB1 if the dataset has 
gone transactional. (I can image that a different dataset implementation may 
need a {{close()}} operation.)

> TDB2 backed Datasets cannot be re-opened.
> -
>
> Key: JENA-1521
> URL: https://issues.apache.org/jira/browse/JENA-1521
> Project: Apache Jena
>  Issue Type: Bug
> Environment: Apache Jena: 3.7.0
> Java: 1.8_162
>Reporter: Greg Albiston
>Priority: Major
>
> If a Dataset connected to with TDB2Factory.connectDataset() is opened, closed 
> and then later re-opened it is reported that the Dataset is closed.
> Opening, closing and re-opening a Dataset with TDBFactory.createDataset() 
> causes no issues.
> Example code to reproduce:
> {noformat}
> public void testTDB2OpenClose() {
> System.out.println("TDB2 Open Close");
>  try {
>  Dataset dataset = TDB2Factory.connectDataset("test_tdb2");
>  dataset.begin(ReadWrite.WRITE);
>  Model defaultModel = dataset.getDefaultModel();
>  
> defaultModel.add(ResourceFactory.createResource("http://example.org/my#SubjA;),
>  ResourceFactory.createProperty("http://example.org/my#PropA;), 
> ResourceFactory.createResource("http://example.org/my#ObjA;));
>  dataset.commit();
>  dataset.end();
>  dataset.close();
> Dataset dataset2 = TDB2Factory.connectDataset("test_tdb2");
>  dataset2.begin(ReadWrite.READ);
>  Model readModel = dataset2.getDefaultModel();
>  Iterator statements = readModel.listStatements();
>  while (statements.hasNext())
> { Statement statement = statements.next(); System.out.println(statement); }
>  dataset2.end();
>  dataset2.close();
>  } catch (Exception ex) \{ System.out.println("Exception: " + 
> ex.getMessage()); }
>  }
>  {noformat}
> {noformat}
>  public void testTDB1OpenClose() {
>  
>  System.out.println("TDB1 Open Close");
>  try {
>  Dataset dataset = TDBFactory.createDataset("test_tdb1");
>  dataset.begin(ReadWrite.WRITE);
>  Model defaultModel = dataset.getDefaultModel();
>  
> defaultModel.add(ResourceFactory.createResource("http://example.org/my#SubjA;),
>  ResourceFactory.createProperty("http://example.org/my#PropA;), 
> ResourceFactory.createResource("http://example.org/my#ObjA;));
>  dataset.commit();
>  dataset.end();
>  dataset.close();
>  
>  Dataset dataset2 = TDBFactory.createDataset("test_tdb1");
>  dataset2.begin(ReadWrite.READ);
>  Model readModel = dataset2.getDefaultModel();
>  Iterator statements = readModel.listStatements();
>  while (statements.hasNext()) \{ Statement statement = statements.next(); 
> System.out.println(statement); }
> dataset2.end();
>  dataset2.close();
>  } catch (Exception ex)
> { System.out.println("Exception: " + ex.getMessage()); }
> }
> {noformat}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (JENA-1521) TDB2 backed Datasets cannot be re-opened.

[Andy Seaborne (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne updated JENA-1521:

Description: 
If a Dataset connected to with TDB2Factory.connectDataset() is opened, closed 
and then later re-opened it is reported that the Dataset is closed.

Opening, closing and re-opening a Dataset with TDBFactory.createDataset() 
causes no issues.

Example code to reproduce:
{noformat}
public void testTDB2OpenClose() {

System.out.println("TDB2 Open Close");
 try {
 Dataset dataset = TDB2Factory.connectDataset("test_tdb2");
 dataset.begin(ReadWrite.WRITE);
 Model defaultModel = dataset.getDefaultModel();
 
defaultModel.add(ResourceFactory.createResource("http://example.org/my#SubjA;), 
ResourceFactory.createProperty("http://example.org/my#PropA;), 
ResourceFactory.createResource("http://example.org/my#ObjA;));
 dataset.commit();
 dataset.end();
 dataset.close();

Dataset dataset2 = TDB2Factory.connectDataset("test_tdb2");
 dataset2.begin(ReadWrite.READ);
 Model readModel = dataset2.getDefaultModel();
 Iterator statements = readModel.listStatements();
 while (statements.hasNext())

{ Statement statement = statements.next(); System.out.println(statement); }
 dataset2.end();
 dataset2.close();
 } catch (Exception ex) \{ System.out.println("Exception: " + ex.getMessage()); 
}
 }
 {noformat}

{noformat}
 public void testTDB1OpenClose() {
 
 System.out.println("TDB1 Open Close");
 try {
 Dataset dataset = TDBFactory.createDataset("test_tdb1");
 dataset.begin(ReadWrite.WRITE);
 Model defaultModel = dataset.getDefaultModel();
 
defaultModel.add(ResourceFactory.createResource("http://example.org/my#SubjA;), 
ResourceFactory.createProperty("http://example.org/my#PropA;), 
ResourceFactory.createResource("http://example.org/my#ObjA;));
 dataset.commit();
 dataset.end();
 dataset.close();
 
 Dataset dataset2 = TDBFactory.createDataset("test_tdb1");
 dataset2.begin(ReadWrite.READ);
 Model readModel = dataset2.getDefaultModel();
 Iterator statements = readModel.listStatements();
 while (statements.hasNext()) \{ Statement statement = statements.next(); 
System.out.println(statement); }

dataset2.end();
 dataset2.close();
 } catch (Exception ex)

{ System.out.println("Exception: " + ex.getMessage()); }

}
{noformat}
 

  was:
If a Dataset connected to with TDB2Factory.connectDataset() is opened, closed 
and then later re-opened it is reported that the Dataset is closed.

Opening, closing and re-opening a Dataset with TDBFactory.createDataset() 
causes no issues.

Example code to reproduce:

public void testTDB2OpenClose() {

System.out.println("TDB2 Open Close");
 try {
 Dataset dataset = TDB2Factory.connectDataset("test_tdb2");
 dataset.begin(ReadWrite.WRITE);
 Model defaultModel = dataset.getDefaultModel();
 
defaultModel.add(ResourceFactory.createResource("http://example.org/my#SubjA;), 
ResourceFactory.createProperty("http://example.org/my#PropA;), 
ResourceFactory.createResource("http://example.org/my#ObjA;));
 dataset.commit();
 dataset.end();
 dataset.close();

Dataset dataset2 = TDB2Factory.connectDataset("test_tdb2");
 dataset2.begin(ReadWrite.READ);
 Model readModel = dataset2.getDefaultModel();
 Iterator statements = readModel.listStatements();
 while (statements.hasNext()) {
 Statement statement = statements.next();
 System.out.println(statement);
 }
 dataset2.end();
 dataset2.close();
 } catch (Exception ex) {
 System.out.println("Exception: " + ex.getMessage());
 }
 }


 public void testTDB1OpenClose() {

System.out.println("TDB1 Open Close");
 try {
 Dataset dataset = TDBFactory.createDataset("test_tdb1");
 dataset.begin(ReadWrite.WRITE);
 Model defaultModel = dataset.getDefaultModel();
 
defaultModel.add(ResourceFactory.createResource("http://example.org/my#SubjA;), 
ResourceFactory.createProperty("http://example.org/my#PropA;), 
ResourceFactory.createResource("http://example.org/my#ObjA;));
 dataset.commit();
 dataset.end();
 dataset.close();

Dataset dataset2 = TDBFactory.createDataset("test_tdb1");
 dataset2.begin(ReadWrite.READ);
 Model readModel = dataset2.getDefaultModel();
 Iterator statements = readModel.listStatements();
 while (statements.hasNext()) {
 Statement statement = statements.next();
 System.out.println(statement);
 }
 dataset2.end();
 dataset2.close();
 } catch (Exception ex) {
 System.out.println("Exception: " + ex.getMessage());
 }
 }

 


> TDB2 backed Datasets cannot be re-opened.
> -
>
> Key: JENA-1521
> URL: https://issues.apache.org/jira/browse/JENA-1521
> Project: Apache Jena
>  Issue Type: Bug
> Environment: Apache Jena: 3.7.0
> Java: 1.8_162
>Reporter: Greg Albiston
>Priority: Major
>
> If a Dataset connected to with TDB2Factory.connectDataset() is opened, closed 
> and then later re-opened it is reported that the Dataset is closed.
> Opening, closing and