[jira] [Comment Edited] (JENA-1499) The TIM dataset retains a memory of named graphs after deleting all quads.

[Adam Jacobs (JIRA)]

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

Adam Jacobs edited comment on JENA-1499 at 3/7/18 12:43 AM:


>From the API side, I've noticed empty graphs are consistently treated as 
>"unimportant" and are often created superfluously.
{code:java}
Dataset ds = DatasetFactory.create();
ds.containsNamedModel("foo");
ds.removeNamedModel("bar");
Iterator iterator = ds.listNames();
System.out.println(iterator.next());
System.out.println(iterator.next());{code}
As mentioned, this is significant when serializing to TRIG.


was (Author: jaco0646):
>From the API side, I've noticed empty graphs are consistently treated as 
>"unimportant" and are often created superfluously.

 

{{Dataset ds = DatasetFactory.create();}}
{{ds.containsNamedModel("foo");}}
{{ds.removeNamedModel("bar");}}
{{Iterator iterator = ds.listNames();}}
{{System.out.println(iterator.next());}}
{{System.out.println(iterator.next());}}

 

As mentioned, this is significant when serializing to TRIG.

> The TIM dataset retains a memory of named graphs after deleting all quads.
> --
>
> Key: JENA-1499
> URL: https://issues.apache.org/jira/browse/JENA-1499
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.6.0
>Reporter: Andy Seaborne
>Priority: Major
>
> Illustration:
> {noformat}
> DatasetGraph dsg = DatasetGraphFactory.createTxnMem();
> Quad q = SSE.parseQuad("(:g :s :p :o)");
> dsg.add(q);
> dsg.delete(q);
> Iter.print(dsg.listGraphNodes());
> {noformat}
> prints {{http://example/g}}.



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

[jira] [Commented] (JENA-1499) The TIM dataset retains a memory of named graphs after deleting all quads.

[Adam Jacobs (JIRA)]

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

Adam Jacobs commented on JENA-1499:
---

>From the API side, I've noticed empty graphs are consistently treated as 
>"unimportant" and are often created superfluously.

 

{{Dataset ds = DatasetFactory.create();}}
{{ds.containsNamedModel("foo");}}
{{ds.removeNamedModel("bar");}}
{{Iterator iterator = ds.listNames();}}
{{System.out.println(iterator.next());}}
{{System.out.println(iterator.next());}}

 

As mentioned, this is significant when serializing to TRIG.

> The TIM dataset retains a memory of named graphs after deleting all quads.
> --
>
> Key: JENA-1499
> URL: https://issues.apache.org/jira/browse/JENA-1499
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.6.0
>Reporter: Andy Seaborne
>Priority: Major
>
> Illustration:
> {noformat}
> DatasetGraph dsg = DatasetGraphFactory.createTxnMem();
> Quad q = SSE.parseQuad("(:g :s :p :o)");
> dsg.add(q);
> dsg.delete(q);
> Iter.print(dsg.listGraphNodes());
> {noformat}
> prints {{http://example/g}}.



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

Re: Possible fuseki/memory store bug

[Dave Reynolds]

Hi Andy,

Thanks for confirming you seeing something similar, glad I wasn't 
hallucinating!


I've tried with '' instead of "" in the shell script version of the test 
with identical results.


Confirmed that using --memTDB the test passes for me.

Dave

On 06/03/18 17:29, Andy Seaborne wrote:

Weird.

I ran this script with Fuseki v3.6.0 "--mem" and also "--memTDB" for 
steps up to and including 6.


https://gist.github.com/afs/cd6953b06985dde37a9581134ec13165

There something going on with TIM because I'm seeing empty graph5 with 
TIM but not with TDB.


I may have seen no results once and then I changed:

 > 6. Check the contents of the store:
 >
 >  rsparql --service http://localhost:3030/ds/query "SELECT * WHERE
 > {Graph ?G {?s ?p ?o}} ORDER BY ?G"

There are "" quotes around a "*"  and it's a script.  Could you try 
''-quotes please?


I'll try step 7.

     Andy

On 05/03/18 23:56, Dave Reynolds wrote:
I've been trying to debug some weird behaviour in my test cases and 
think they are due to a bug in memory-backed fuseki stores.


However, the behaviour is so odd and hard to reproduce I'd like some 
confirmation that someone else sees the same effect before opening a 
JIRA.


# Steps to reproduce

[Sorry this is convoluted but all my attempts to simplify fail to show 
the suspected bug.]


1. Fresh download of fuseki 3.6.0.

2. Start an in memory server in one shell:

 fuseki-server --mem --update /ds

3. Create test data with two statements about one resource:

 echo 'prefix rdfs:  
prefix eg:    
eg:r4 a eg:Resource; rdfs:label "r 4" .' > update.ttl

4. Use the graph REST API to put the data into a named graph:

 s-put http://localhost:3030/ds/data http://localhost/graph5 
update.ttl


5. Run a sparql update which will delete the original statements from 
the graph and add some replacement statements to a new graph:


 rupdate --service=http://localhost:3030/ds/update '
 DELETE {GRAPH ?G { ?p ?o}} WHERE {GRAPH 
?G { ?p ?o}};

 INSERT DATA { GRAPH  {
  
 "r 4 modified" .
  
 
 .

 } }'

6. Check the contents of the store:

 rsparql --service http://localhost:3030/ds/query "SELECT * WHERE 
{Graph ?G {?s ?p ?o}} ORDER BY ?G"


At this point the store *should* contain two statements in graph 
http://localhost/test/r4. With a TDB-backed fuseki that's what I see. 
With the memory backed fuseki I see an apparently empty store.


If other named graphs are populated with other unrelated data they 
will seem to have disappeared as well.


7. Now reinsert the original data, running step 4 again and check by 
running step 6 again. At this point both the "missing" statements from 
graph http://localhost/test/r4 reappear, as does the reinserted 
original statements in http://localhost/graph5.


# Simplifying the test case

So far ...

   - I've failed to reproduce this outside of fuseki.

   - I've failed to reproduce this without mixing graph operations and 
update operations.


   - If I reduce the inserted/updated data to a single statement 
instead of a pair of statements it passes.


   - If I try with at empty TDB store it passes.

   - I get the same behaviour from 3.4.0 as from 3.6.0.

Any of these failures may be user error on my part, it has been so 
hard turning an apparently non-deterministic error into something 
reproducible that I'm no longer sure of anything :(


Am I going mad or does anyone else see the same behaviour?

Dave

[jira] [Comment Edited] (JENA-1499) The TIM dataset retains a memory of named graphs after deleting all quads.

[Andy Seaborne (JIRA)]

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

Andy Seaborne edited comment on JENA-1499 at 3/6/18 10:41 PM:
--

Could you explain a bit about what {{QuadTableForm.GSPO.listGraphNodes}} is 
doing? I haven't looked at these details of {{QuadTableForm}} before. Can empty 
graphs appear in other ways? Does traversal of {{G\?\?\?}} simply on generate 
quads if the subtree is partial (i.e. empty) some how in {{GS\?\?}} ?




was (Author: andy.seaborne):
Could you explain a bit about what {{QuadTableForm.GSPO.listGraphNodes}} is 
doing? I haven't looked at these details of `QuadTableForm` before. Can empty 
graphs appear in other ways? Does traversal of {{G\?\?\?}} simply on generate 
quads if the subtree is partial (i.e. empty) some how in {{GS\?\?}} ?



> The TIM dataset retains a memory of named graphs after deleting all quads.
> --
>
> Key: JENA-1499
> URL: https://issues.apache.org/jira/browse/JENA-1499
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.6.0
>Reporter: Andy Seaborne
>Priority: Major
>
> Illustration:
> {noformat}
> DatasetGraph dsg = DatasetGraphFactory.createTxnMem();
> Quad q = SSE.parseQuad("(:g :s :p :o)");
> dsg.add(q);
> dsg.delete(q);
> Iter.print(dsg.listGraphNodes());
> {noformat}
> prints {{http://example/g}}.



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

[jira] [Commented] (JENA-1499) The TIM dataset retains a memory of named graphs after deleting all quads.

[Andy Seaborne (JIRA)]

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

Andy Seaborne commented on JENA-1499:
-

Could you explain a bit about what {{QuadTableForm.GSPO.listGraphNodes}} is 
doing? I haven't looked at these details of `QuadTableForm` before. Can empty 
graphs appear in other ways? Does traversal of {{G\?\?\?}} simply on generate 
quads if the subtree is partial (i.e. empty) some how in {{GS\?\?}} ?



> The TIM dataset retains a memory of named graphs after deleting all quads.
> --
>
> Key: JENA-1499
> URL: https://issues.apache.org/jira/browse/JENA-1499
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.6.0
>Reporter: Andy Seaborne
>Priority: Major
>
> Illustration:
> {noformat}
> DatasetGraph dsg = DatasetGraphFactory.createTxnMem();
> Quad q = SSE.parseQuad("(:g :s :p :o)");
> dsg.add(q);
> dsg.delete(q);
> Iter.print(dsg.listGraphNodes());
> {noformat}
> prints {{http://example/g}}.



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

[jira] [Commented] (JENA-1454) Configurable ResultSet reading and writing

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1454:
--

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

https://github.com/apache/jena/pull/373#discussion_r172680400
  
--- Diff: 
jena-fuseki2/jena-fuseki-core/src/main/java/org/apache/jena/fuseki/servlets/ResponseResultSet.java
 ---
@@ -131,26 +130,30 @@ public static void doResponseResultSet(HttpAction 
action, ResultSet resultSet, P
 contentType = contentTypeTextPlain ;
 
 // Some kind of general dispatch is neater but there are quite a 
few special cases.
+// text/plain is special because there is no ResultSetWriter for 
it (yet). 
+// Text plain is special because of the formatting by prologue.
+// text/plain is not a registered result set language. 
 //
 // JSON is special because of ?callback
-// 
+//
 // XML is special because of
 // (1) charset is a feature of XML, not the response 
 // (2) ?stylesheet=
 //
 // Thrift is special because
 // (1) charset is meaningless
 // (2) there is no boolean result form.
-//
-// Text plain is special because of the formatting by prologue.
-
+
+if ( Objects.equals(serializationType, contentTypeTextPlain) ) {
--- End diff --

Style, no more :  `Objects.equals` copes with null in the same way the 
back-to-front `constant.equals(variable)` is also a null-defending idiom. Not 
that there will be nulls.  It could be a switch on strings. It should be `lang` 
driven but there is no text result set writer ATM and text is odd because it 
uses prefixes and no other result set format does.

This is a quick fix to restore what become broken in the JENA-1454 redesign.


> Configurable ResultSet reading and writing
> --
>
> Key: JENA-1454
> URL: https://issues.apache.org/jira/browse/JENA-1454
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.7.0
>
>
> Same patterns as {{RDFParser}}, {{RDFWriter}}.



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

[GitHub] jena pull request #373: JENA-1454: Fix to handle text output format.

[afs]

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

https://github.com/apache/jena/pull/373#discussion_r172680400
  
--- Diff: 
jena-fuseki2/jena-fuseki-core/src/main/java/org/apache/jena/fuseki/servlets/ResponseResultSet.java
 ---
@@ -131,26 +130,30 @@ public static void doResponseResultSet(HttpAction 
action, ResultSet resultSet, P
 contentType = contentTypeTextPlain ;
 
 // Some kind of general dispatch is neater but there are quite a 
few special cases.
+// text/plain is special because there is no ResultSetWriter for 
it (yet). 
+// Text plain is special because of the formatting by prologue.
+// text/plain is not a registered result set language. 
 //
 // JSON is special because of ?callback
-// 
+//
 // XML is special because of
 // (1) charset is a feature of XML, not the response 
 // (2) ?stylesheet=
 //
 // Thrift is special because
 // (1) charset is meaningless
 // (2) there is no boolean result form.
-//
-// Text plain is special because of the formatting by prologue.
-
+
+if ( Objects.equals(serializationType, contentTypeTextPlain) ) {
--- End diff --

Style, no more :  `Objects.equals` copes with null in the same way the 
back-to-front `constant.equals(variable)` is also a null-defending idiom. Not 
that there will be nulls.  It could be a switch on strings. It should be `lang` 
driven but there is no text result set writer ATM and text is odd because it 
uses prefixes and no other result set format does.

This is a quick fix to restore what become broken in the JENA-1454 redesign.


---

[jira] [Commented] (JENA-1499) The TIM dataset retains a memory of named graphs after deleting all quads.

[A. Soroka (JIRA)]

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

A. Soroka commented on JENA-1499:
-

Well, surprising is not good.

Which way to play this? Prune all empty graphs, or make sure that empty graphs 
appear from {{listGraphNodes()}}?

> The TIM dataset retains a memory of named graphs after deleting all quads.
> --
>
> Key: JENA-1499
> URL: https://issues.apache.org/jira/browse/JENA-1499
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.6.0
>Reporter: Andy Seaborne
>Priority: Major
>
> Illustration:
> {noformat}
> DatasetGraph dsg = DatasetGraphFactory.createTxnMem();
> Quad q = SSE.parseQuad("(:g :s :p :o)");
> dsg.add(q);
> dsg.delete(q);
> Iter.print(dsg.listGraphNodes());
> {noformat}
> prints {{http://example/g}}.



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

[jira] [Commented] (JENA-1499) The TIM dataset retains a memory of named graphs after deleting all quads.

[Andy Seaborne (JIRA)]

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

Andy Seaborne commented on JENA-1499:
-

It's not a bug but it is inconsistent. This does not print anything.

{noformat}
DatasetGraph dsg = DatasetGraphFactory.createTxnMem();
UpdateAction.parseExecute("CREATE GRAPH ", dsg);
Iter.print(dsg.listGraphNodes());
{noformat}

I'd rather the TriG writers didn't have to test each named graph for being 
empty.

{{DatasetGraphFactory.createGeneral()}} is the exception and does have empty 
graphs but also it does print the name in the example.


> The TIM dataset retains a memory of named graphs after deleting all quads.
> --
>
> Key: JENA-1499
> URL: https://issues.apache.org/jira/browse/JENA-1499
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.6.0
>Reporter: Andy Seaborne
>Priority: Major
>
> Illustration:
> {noformat}
> DatasetGraph dsg = DatasetGraphFactory.createTxnMem();
> Quad q = SSE.parseQuad("(:g :s :p :o)");
> dsg.add(q);
> dsg.delete(q);
> Iter.print(dsg.listGraphNodes());
> {noformat}
> prints {{http://example/g}}.



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

[jira] [Commented] (JENA-1499) The TIM dataset retains a memory of named graphs after deleting all quads.

[A. Soroka (JIRA)]

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

A. Soroka commented on JENA-1499:
-

is this actually a bug? I was (perhaps wrongly) under the impression that this 
is perfectly correct behavior. From 
[https://www.w3.org/TR/rdf11-concepts/#section-dataset]:
{quote}Some [RDF dataset|https://www.w3.org/TR/rdf11-concepts/#dfn-rdf-dataset] 
implementations do not track empty [named 
graphs|https://www.w3.org/TR/rdf11-concepts/#dfn-named-graph]. Applications can 
avoid interoperability issues by not ascribing importance to the presence or 
absence of empty named graphs.
{quote}
That having been said, if we want to make a guarantee across Jena datasets (or 
if we already do and I just didn't know) of course we can make it so.

> The TIM dataset retains a memory of named graphs after deleting all quads.
> --
>
> Key: JENA-1499
> URL: https://issues.apache.org/jira/browse/JENA-1499
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.6.0
>Reporter: Andy Seaborne
>Priority: Major
>
> Illustration:
> {noformat}
> DatasetGraph dsg = DatasetGraphFactory.createTxnMem();
> Quad q = SSE.parseQuad("(:g :s :p :o)");
> dsg.add(q);
> dsg.delete(q);
> Iter.print(dsg.listGraphNodes());
> {noformat}
> prints {{http://example/g}}.



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

[jira] [Created] (JENA-1499) The TIM dataset retains a memory of named graphs after deleting all quads.

[Andy Seaborne (JIRA)]

Andy Seaborne created JENA-1499:
---

 Summary: The TIM dataset retains a memory of named graphs after 
deleting all quads.
 Key: JENA-1499
 URL: https://issues.apache.org/jira/browse/JENA-1499
 Project: Apache Jena
  Issue Type: Bug
Affects Versions: Jena 3.6.0
Reporter: Andy Seaborne


Illustration:
{noformat}
DatasetGraph dsg = DatasetGraphFactory.createTxnMem();
Quad q = SSE.parseQuad("(:g :s :p :o)");
dsg.add(q);
dsg.delete(q);
Iter.print(dsg.listGraphNodes());
{noformat}

prints {{http://example/g}}.



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

[jira] [Commented] (JENA-1454) Configurable ResultSet reading and writing

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1454:
--

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

https://github.com/apache/jena/pull/373#discussion_r172649522
  
--- Diff: 
jena-fuseki2/jena-fuseki-core/src/main/java/org/apache/jena/fuseki/servlets/ResponseResultSet.java
 ---
@@ -131,26 +130,30 @@ public static void doResponseResultSet(HttpAction 
action, ResultSet resultSet, P
 contentType = contentTypeTextPlain ;
 
 // Some kind of general dispatch is neater but there are quite a 
few special cases.
+// text/plain is special because there is no ResultSetWriter for 
it (yet). 
+// Text plain is special because of the formatting by prologue.
+// text/plain is not a registered result set language. 
 //
 // JSON is special because of ?callback
-// 
+//
 // XML is special because of
 // (1) charset is a feature of XML, not the response 
 // (2) ?stylesheet=
 //
 // Thrift is special because
 // (1) charset is meaningless
 // (2) there is no boolean result form.
-//
-// Text plain is special because of the formatting by prologue.
-
+
+if ( Objects.equals(serializationType, contentTypeTextPlain) ) {
--- End diff --

Just out of curiosity-- why `Objects.equals` here instead of 
`contentTypeTextPlain.equals` or `serializationType.equals`?


> Configurable ResultSet reading and writing
> --
>
> Key: JENA-1454
> URL: https://issues.apache.org/jira/browse/JENA-1454
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.7.0
>
>
> Same patterns as {{RDFParser}}, {{RDFWriter}}.



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

[jira] [Commented] (JENA-1454) Configurable ResultSet reading and writing

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1454:
--

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

https://github.com/apache/jena/pull/373#discussion_r172649617
  
--- Diff: 
jena-fuseki2/jena-fuseki-core/src/main/java/org/apache/jena/fuseki/servlets/ResponseResultSet.java
 ---
@@ -131,26 +130,30 @@ public static void doResponseResultSet(HttpAction 
action, ResultSet resultSet, P
 contentType = contentTypeTextPlain ;
 
 // Some kind of general dispatch is neater but there are quite a 
few special cases.
+// text/plain is special because there is no ResultSetWriter for 
it (yet). 
+// Text plain is special because of the formatting by prologue.
+// text/plain is not a registered result set language. 
 //
 // JSON is special because of ?callback
-// 
+//
 // XML is special because of
 // (1) charset is a feature of XML, not the response 
 // (2) ?stylesheet=
 //
 // Thrift is special because
 // (1) charset is meaningless
 // (2) there is no boolean result form.
-//
-// Text plain is special because of the formatting by prologue.
-
+
+if ( Objects.equals(serializationType, contentTypeTextPlain) ) {
--- End diff --

Oh, I see-- this was cut from down below. NM.


> Configurable ResultSet reading and writing
> --
>
> Key: JENA-1454
> URL: https://issues.apache.org/jira/browse/JENA-1454
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.7.0
>
>
> Same patterns as {{RDFParser}}, {{RDFWriter}}.



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

[GitHub] jena pull request #373: JENA-1454: Fix to handle text output format.

[ajs6f]

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

https://github.com/apache/jena/pull/373#discussion_r172649617
  
--- Diff: 
jena-fuseki2/jena-fuseki-core/src/main/java/org/apache/jena/fuseki/servlets/ResponseResultSet.java
 ---
@@ -131,26 +130,30 @@ public static void doResponseResultSet(HttpAction 
action, ResultSet resultSet, P
 contentType = contentTypeTextPlain ;
 
 // Some kind of general dispatch is neater but there are quite a 
few special cases.
+// text/plain is special because there is no ResultSetWriter for 
it (yet). 
+// Text plain is special because of the formatting by prologue.
+// text/plain is not a registered result set language. 
 //
 // JSON is special because of ?callback
-// 
+//
 // XML is special because of
 // (1) charset is a feature of XML, not the response 
 // (2) ?stylesheet=
 //
 // Thrift is special because
 // (1) charset is meaningless
 // (2) there is no boolean result form.
-//
-// Text plain is special because of the formatting by prologue.
-
+
+if ( Objects.equals(serializationType, contentTypeTextPlain) ) {
--- End diff --

Oh, I see-- this was cut from down below. NM.


---

[GitHub] jena pull request #373: JENA-1454: Fix to handle text output format.

[ajs6f]

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

https://github.com/apache/jena/pull/373#discussion_r172649522
  
--- Diff: 
jena-fuseki2/jena-fuseki-core/src/main/java/org/apache/jena/fuseki/servlets/ResponseResultSet.java
 ---
@@ -131,26 +130,30 @@ public static void doResponseResultSet(HttpAction 
action, ResultSet resultSet, P
 contentType = contentTypeTextPlain ;
 
 // Some kind of general dispatch is neater but there are quite a 
few special cases.
+// text/plain is special because there is no ResultSetWriter for 
it (yet). 
+// Text plain is special because of the formatting by prologue.
+// text/plain is not a registered result set language. 
 //
 // JSON is special because of ?callback
-// 
+//
 // XML is special because of
 // (1) charset is a feature of XML, not the response 
 // (2) ?stylesheet=
 //
 // Thrift is special because
 // (1) charset is meaningless
 // (2) there is no boolean result form.
-//
-// Text plain is special because of the formatting by prologue.
-
+
+if ( Objects.equals(serializationType, contentTypeTextPlain) ) {
--- End diff --

Just out of curiosity-- why `Objects.equals` here instead of 
`contentTypeTextPlain.equals` or `serializationType.equals`?


---

[jira] [Commented] (JENA-1454) Configurable ResultSet reading and writing

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1454:
--

GitHub user afs opened a pull request:

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

JENA-1454: Fix to handle text output format.

Bug fix to JENA-1454.

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

$ git pull https://github.com/afs/jena fuseki-text

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

https://github.com/apache/jena/pull/373.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 #373


commit b5b4b13ad6bafb08c15a8588cd2ad43ec0f515e2
Author: Andy Seaborne 
Date:   2018-03-06T19:50:19Z

JENA-1454: Fix to handle text output format.




> Configurable ResultSet reading and writing
> --
>
> Key: JENA-1454
> URL: https://issues.apache.org/jira/browse/JENA-1454
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.7.0
>
>
> Same patterns as {{RDFParser}}, {{RDFWriter}}.



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

[GitHub] jena pull request #373: JENA-1454: Fix to handle text output format.

[afs]

GitHub user afs opened a pull request:

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

JENA-1454: Fix to handle text output format.

Bug fix to JENA-1454.

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

$ git pull https://github.com/afs/jena fuseki-text

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

https://github.com/apache/jena/pull/373.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 #373


commit b5b4b13ad6bafb08c15a8588cd2ad43ec0f515e2
Author: Andy Seaborne 
Date:   2018-03-06T19:50:19Z

JENA-1454: Fix to handle text output format.




---

[GitHub] jena pull request #353: Refactoring complex methods of classes FBRuleInfGrap...

[santiago-a-vidal]

Github user santiago-a-vidal closed the pull request at:

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


---

[GitHub] jena issue #353: Refactoring complex methods of classes FBRuleInfGraph and L...

[santiago-a-vidal]

Github user santiago-a-vidal commented on the issue:

https://github.com/apache/jena/pull/353
  
Hi, thanks a lot for the feedback. I agree with you. The refactoring of 
complex methods in a class with no change since its initial implementation (and 
not expected to be modified in the future) may have low  priority when compared 
to a complex method in a class that received modifications in the last 10 most 
significant revisions. 

Thanks again.

Cheers,


---

Re: Possible fuseki/memory store bug

[Andy Seaborne]

Weird.

I ran this script with Fuseki v3.6.0 "--mem" and also "--memTDB" for 
steps up to and including 6.


https://gist.github.com/afs/cd6953b06985dde37a9581134ec13165

There something going on with TIM because I'm seeing empty graph5 with 
TIM but not with TDB.


I may have seen no results once and then I changed:

> 6. Check the contents of the store:
>
>  rsparql --service http://localhost:3030/ds/query "SELECT * WHERE
> {Graph ?G {?s ?p ?o}} ORDER BY ?G"

There are "" quotes around a "*"  and it's a script.  Could you try 
''-quotes please?


I'll try step 7.

Andy

On 05/03/18 23:56, Dave Reynolds wrote:
I've been trying to debug some weird behaviour in my test cases and 
think they are due to a bug in memory-backed fuseki stores.


However, the behaviour is so odd and hard to reproduce I'd like some 
confirmation that someone else sees the same effect before opening a JIRA.


# Steps to reproduce

[Sorry this is convoluted but all my attempts to simplify fail to show 
the suspected bug.]


1. Fresh download of fuseki 3.6.0.

2. Start an in memory server in one shell:

     fuseki-server --mem --update /ds

3. Create test data with two statements about one resource:

     echo 'prefix rdfs:  
prefix eg:    
eg:r4 a eg:Resource; rdfs:label "r 4" .' > update.ttl

4. Use the graph REST API to put the data into a named graph:

     s-put http://localhost:3030/ds/data http://localhost/graph5 update.ttl

5. Run a sparql update which will delete the original statements from 
the graph and add some replacement statements to a new graph:


     rupdate --service=http://localhost:3030/ds/update '
     DELETE {GRAPH ?G { ?p ?o}} WHERE {GRAPH 
?G { ?p ?o}};

     INSERT DATA { GRAPH  {
      
 "r 4 modified" .
      
 
 .

     } }'

6. Check the contents of the store:

     rsparql --service http://localhost:3030/ds/query "SELECT * WHERE 
{Graph ?G {?s ?p ?o}} ORDER BY ?G"


At this point the store *should* contain two statements in graph 
http://localhost/test/r4. With a TDB-backed fuseki that's what I see. 
With the memory backed fuseki I see an apparently empty store.


If other named graphs are populated with other unrelated data they will 
seem to have disappeared as well.


7. Now reinsert the original data, running step 4 again and check by 
running step 6 again. At this point both the "missing" statements from 
graph http://localhost/test/r4 reappear, as does the reinserted original 
statements in http://localhost/graph5.


# Simplifying the test case

So far ...

   - I've failed to reproduce this outside of fuseki.

   - I've failed to reproduce this without mixing graph operations and 
update operations.


   - If I reduce the inserted/updated data to a single statement instead 
of a pair of statements it passes.


   - If I try with at empty TDB store it passes.

   - I get the same behaviour from 3.4.0 as from 3.6.0.

Any of these failures may be user error on my part, it has been so hard 
turning an apparently non-deterministic error into something 
reproducible that I'm no longer sure of anything :(


Am I going mad or does anyone else see the same behaviour?

Dave

[GitHub] jena issue #353: Refactoring complex methods of classes FBRuleInfGraph and L...

[afs]

Github user afs commented on the issue:

https://github.com/apache/jena/pull/353
  
Thank you to @santiago-a-vidal for this work! It is really interesting to 
have Bandago prototype applied the code base.   Given the age of Jena, and 
evolution of contributors skills, I'm sure that many places would be written 
somewhat differently by today's standards, my own contributions especially.

The code here has not changed in 4 years (and that was a patch) so there is 
a balance to be discussed between changing it and leaving proven code as-is.



---

[GitHub] jena pull request #372: Reformatting + two RiotChars functions.

[ajs6f]

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

https://github.com/apache/jena/pull/372#discussion_r172582451
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/riot/lang/BlankNodeAllocatorGlobal.java 
---
@@ -18,41 +18,39 @@
 
 package org.apache.jena.riot.lang;
 
-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.graph.NodeFactory ;
+import org.apache.jena.graph.Node;
+import org.apache.jena.graph.NodeFactory;
 
-/** Allocate blank nodes by creating a randomly generated blank node.
- *  This allocator has arbitrary sized state. 
+/**
+ * Allocate blank nodes by creating a randomly generated blank node.
+ * This allocator has arbitrary sized internal state needed to record
+ * the label to node mapping.
  */
 
 public class BlankNodeAllocatorGlobal implements BlankNodeAllocator
 {
-Map map = new HashMap<>() ;
+Map map = new HashMap<>();
 
 public BlankNodeAllocatorGlobal()  {}
 
 @Override
-public void reset() { map.clear() ; }
+public void reset() { map.clear(); }
 
 @Override
-public Node alloc(String label)
-{
-Node b = map.get(label) ;
-if ( b == null )
-{
-b = create() ;
-map.put(label, b) ;
+public Node alloc(String label) {
+Node b = map.get(label);
--- End diff --

Maybe just `return map.computeIfAbsent(x->create())`?


---

[GitHub] jena pull request #372: Reformatting + two RiotChars functions.

[afs]

GitHub user afs opened a pull request:

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

Reformatting + two RiotChars functions.

Minor : reformatting around blank node allocation and two library 
functions, triggered by checking blank nodes formats.

* `RiotChars.isHexCharLC`
* `RiotChars.isHexCharUC`


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

$ git pull https://github.com/afs/jena blanknodes

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

https://github.com/apache/jena/pull/372.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 #372


commit 7163eb824724a568df96f508ed31abd38b6f9b80
Author: Andy Seaborne 
Date:   2017-12-25T13:08:47Z

Check comments and tidy up.

commit dc8fb522d6b9cacea7440c6aa36f1d9fe02d5a89
Author: Andy Seaborne 
Date:   2017-12-28T21:08:46Z

More tests for hexadecimal digits.




---

[jira] [Commented] (JENA-632) Generate JSON from SPARQL directly.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-632:
-

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/114
  
Hey, @kinow , is this ready for rebase and review? I can try rebasing it 
into a separate PR, or you can if you have time... then (hopefully) we can get 
it in!


> Generate JSON from SPARQL directly.
> ---
>
> Key: JENA-632
> URL: https://issues.apache.org/jira/browse/JENA-632
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ, Fuseki
>Reporter: Andy Seaborne
>Assignee: Bruno P. Kinoshita
>Priority: Minor
>  Labels: java, javacc
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> The capability to generate JSON directly from a SPARQL (or extended SPARQL) 
> query would enable the creation of JSON data API over published linked data.
> This project would cover:
> # Design and publication of a design.
> # Refinement of design based on community feed
> # Implementation, including testing.
> # Refinement of implementation based on community feed
> Skills required: Java, some parser work, design and discussion with the user 
> community, basic understanding of HTTP and content negotiation.



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

[GitHub] jena issue #114: JENA-632: Generate JSON from SPARQL directly

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/114
  
Hey, @kinow , is this ready for rebase and review? I can try rebasing it 
into a separate PR, or you can if you have time... then (hopefully) we can get 
it in!


---

[GitHub] jena issue #353: Refactoring complex methods of classes FBRuleInfGraph and L...

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/353
  
I simply don't know enough about our inferencing gear to comment on 
this… @der, can you say anything?


---

[jira] [Resolved] (JENA-1498) Provide an example Fuseki backup script.

[Andy Seaborne (JIRA)]

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

Andy Seaborne resolved JENA-1498.
-
   Resolution: Done
 Assignee: Andy Seaborne
Fix Version/s: Jena 3.7.0

> Provide an example Fuseki backup script.
> 
>
> Key: JENA-1498
> URL: https://issues.apache.org/jira/browse/JENA-1498
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.7.0
>
>




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

[jira] [Commented] (JENA-1492) Transactions not passed down for nested models.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1492:
--

Github user asfgit closed the pull request at:

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


> Transactions not passed down for nested models.
> ---
>
> Key: JENA-1492
> URL: https://issues.apache.org/jira/browse/JENA-1492
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki, TDB, TDB2
>Affects Versions: Jena 3.7.0
>Reporter: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.7.0
>
> Attachments: config-tdb2-model.ttl
>
>
> From [users@ 
> email|https://lists.apache.org/thread.html/eacd92488360298a4916b2b1b0cf2d299797140be1960f84410f9b5d@%3Cusers.jena.apache.org%3E],
>  after the configuration sorted out.
> Hierarchies of models, such as inference models, on top of a TBD2 
> backed-graph do not pass down the transaction leading to
> {noformat}
> org.apache.jena.dboe.transaction.txn.TransactionException: Not in a 
> transaction
>     at 
> org.apache.jena.dboe.transaction.txn.TransactionalComponentLifecycle.checkTxn(TransactionalComponentLifecycle.java:417)
>     at 
> org.apache.jena.dboe.trans.bplustree.BPlusTree.getRootRead(BPlusTree.java:159)
>     at 
> org.apache.jena.dboe.trans.bplustree.BPlusTree.iterator(BPlusTree.java:348)
>     at 
> org.apache.jena.tdb2.store.tupletable.TupleIndexRecord.all(TupleIndexRecord.java:251)
>     at 
> org.apache.jena.tdb2.store.tupletable.TupleTable.find(TupleTable.java:148)
>     at 
> org.apache.jena.tdb2.store.nodetupletable.NodeTupleTableConcrete.find(NodeTupleTableConcrete.java:161)
>     at 
> org.apache.jena.tdb2.store.nodetupletable.NodeTupleTableConcrete.find(NodeTupleTableConcrete.java:150)
>     at 
> org.apache.jena.tdb2.store.nodetupletable.NodeTupleTableConcrete.findAsNodeIds(NodeTupleTableConcrete.java:141)
>     at org.apache.jena.tdb2.store.TripleTable.find(TripleTable.java:64)
>     at 
> org.apache.jena.tdb2.store.DatasetGraphTDB.findInDftGraph(DatasetGraphTDB.java:110)
>     at 
> org.apache.jena.sparql.core.DatasetGraphBaseFind.find(DatasetGraphBaseFind.java:47)
>     at 
> org.apache.jena.sparql.core.DatasetGraphWrapper.find(DatasetGraphWrapper.java:152)
>     at org.apache.jena.sparql.core.GraphView.graphBaseFind(GraphView.java:125)
>     at org.apache.jena.graph.impl.GraphBase.find(GraphBase.java:255)
> {noformat}
> Example configuration (full version attached):
> {noformat}
> :service  a   fuseki:Service ;
>     fuseki:dataset    :dataset ;
> ...
> ## Wrapper: Datset containing one TDB2-backed graph
> :dataset a ja:RDFDataset ;
>     ja:defaultGraph   :graph .
> ##  TDB2-backed graph
> :graph rdf:type tdb2:GraphTDB ;
>     tdb2:dataset :datasetTDB2 .
> ## TDB2 database
> :datasetTDB2 rdf:type tdb2:DatasetTDB2 ;
>     tdb2:location "DB2".
> {noformat}
>  



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

[jira] [Resolved] (JENA-1492) Transactions not passed down for nested models.

[Andy Seaborne (JIRA)]

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

Andy Seaborne resolved JENA-1492.
-
   Resolution: Fixed
 Assignee: Andy Seaborne
Fix Version/s: Jena 3.7.0

> Transactions not passed down for nested models.
> ---
>
> Key: JENA-1492
> URL: https://issues.apache.org/jira/browse/JENA-1492
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki, TDB, TDB2
>Affects Versions: Jena 3.7.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.7.0
>
> Attachments: config-tdb2-model.ttl
>
>
> From [users@ 
> email|https://lists.apache.org/thread.html/eacd92488360298a4916b2b1b0cf2d299797140be1960f84410f9b5d@%3Cusers.jena.apache.org%3E],
>  after the configuration sorted out.
> Hierarchies of models, such as inference models, on top of a TBD2 
> backed-graph do not pass down the transaction leading to
> {noformat}
> org.apache.jena.dboe.transaction.txn.TransactionException: Not in a 
> transaction
>     at 
> org.apache.jena.dboe.transaction.txn.TransactionalComponentLifecycle.checkTxn(TransactionalComponentLifecycle.java:417)
>     at 
> org.apache.jena.dboe.trans.bplustree.BPlusTree.getRootRead(BPlusTree.java:159)
>     at 
> org.apache.jena.dboe.trans.bplustree.BPlusTree.iterator(BPlusTree.java:348)
>     at 
> org.apache.jena.tdb2.store.tupletable.TupleIndexRecord.all(TupleIndexRecord.java:251)
>     at 
> org.apache.jena.tdb2.store.tupletable.TupleTable.find(TupleTable.java:148)
>     at 
> org.apache.jena.tdb2.store.nodetupletable.NodeTupleTableConcrete.find(NodeTupleTableConcrete.java:161)
>     at 
> org.apache.jena.tdb2.store.nodetupletable.NodeTupleTableConcrete.find(NodeTupleTableConcrete.java:150)
>     at 
> org.apache.jena.tdb2.store.nodetupletable.NodeTupleTableConcrete.findAsNodeIds(NodeTupleTableConcrete.java:141)
>     at org.apache.jena.tdb2.store.TripleTable.find(TripleTable.java:64)
>     at 
> org.apache.jena.tdb2.store.DatasetGraphTDB.findInDftGraph(DatasetGraphTDB.java:110)
>     at 
> org.apache.jena.sparql.core.DatasetGraphBaseFind.find(DatasetGraphBaseFind.java:47)
>     at 
> org.apache.jena.sparql.core.DatasetGraphWrapper.find(DatasetGraphWrapper.java:152)
>     at org.apache.jena.sparql.core.GraphView.graphBaseFind(GraphView.java:125)
>     at org.apache.jena.graph.impl.GraphBase.find(GraphBase.java:255)
> {noformat}
> Example configuration (full version attached):
> {noformat}
> :service  a   fuseki:Service ;
>     fuseki:dataset    :dataset ;
> ...
> ## Wrapper: Datset containing one TDB2-backed graph
> :dataset a ja:RDFDataset ;
>     ja:defaultGraph   :graph .
> ##  TDB2-backed graph
> :graph rdf:type tdb2:GraphTDB ;
>     tdb2:dataset :datasetTDB2 .
> ## TDB2 database
> :datasetTDB2 rdf:type tdb2:DatasetTDB2 ;
>     tdb2:location "DB2".
> {noformat}
>  



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

[jira] [Commented] (JENA-1391) Add Convenience Methods to Dataset

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1391:
--

Github user asfgit closed the pull request at:

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


> Add Convenience Methods to Dataset
> --
>
> Key: JENA-1391
> URL: https://issues.apache.org/jira/browse/JENA-1391
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ
>Affects Versions: Jena 3.4.0
>Reporter: Adam Jacobs
>Assignee: A. Soroka
>Priority: Trivial
> Fix For: Jena 3.7.0
>
>
> The Dataset interface could provide several convenience methods similar to 
> the Model interface, allowing usability of RDF quads on par with RDF triples. 
> Specific examples include,
> # add(Dataset)
> # remove(Dataset)
> # union(Dataset)
> # intersection(Dataset)
> # difference(Dataset)
> # isEmpty()
> Following is a possible implementation of these methods.
> {code:java}
> default Dataset add(Dataset d) {
> this.getDefaultModel().add(d.getDefaultModel());
> d.listNames().forEachRemaining(name -> 
> this.getNamedModel(name).add(d.getNamedModel(name)));
> return this;
> }
> default Dataset remove(Dataset d) {
> this.getDefaultModel().remove(d.getDefaultModel());
> d.listNames().forEachRemaining(name -> 
> this.getNamedModel(name).remove(d.getNamedModel(name)));
> return this;
> }
> default Dataset union(Dataset d) {
> return DatasetFactory.create().add(this).add(d);
> }
> default Dataset difference(Dataset d) {
> Dataset output = DatasetFactory.create();
> 
> output.setDefaultModel(this.getDefaultModel().difference(d.getDefaultModel()));
> this.listNames().forEachRemaining(name -> {
> Model difference = 
> this.getNamedModel(name).difference(d.getNamedModel(name));
> if (!difference.isEmpty()) output.addNamedModel(name, difference);
> });
> return output;
> }
> default Dataset intersection(Dataset d) {
> Dataset output = DatasetFactory.create();
> 
> output.setDefaultModel(this.getDefaultModel().intersection(d.getDefaultModel()));
> Set names = this.names();
> names.retainAll(d.names());
> names.forEach(name -> {
> Model intersection = 
> this.getNamedModel(name).intersection(d.getNamedModel(name));
> if (!intersection.isEmpty()) output.addNamedModel(name, 
> intersection);
> });
> return output;
> }
> default Set names() {
> Set names = new HashSet<>();
> this.listNames().forEachRemaining(names::add);
> return names;
> }
> default boolean isEmpty() {
> return this.asDatasetGraph().isEmpty();
> }
> {code}



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

[jira] [Commented] (JENA-1498) Provide an example Fuseki backup script.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1498:
--

Github user asfgit closed the pull request at:

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


> Provide an example Fuseki backup script.
> 
>
> Key: JENA-1498
> URL: https://issues.apache.org/jira/browse/JENA-1498
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Andy Seaborne
>Priority: Major
>




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

[GitHub] jena pull request #369: JENA-1492: Pass down transactions from general datas...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] jena pull request #371: JENA-1498: Fuseki backup script

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] jena pull request #367: JENA-1391: Add methods for ModelCollectors to API in...

[asfgit]

Github user asfgit closed the pull request at:

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


---