[GitHub] jena pull request: JENA-1083: Refactoring in TupleTable and subtyp...

[afs]

Github user afs commented on the pull request:

https://github.com/apache/jena/pull/106#issuecomment-163886614
  
The whitespace changes make it tricky to follow the real changes so I have 
converted all the file in the package in master from tabs to spaces to give a 
common reference point.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-1083) MInor refactoring in TupleTables

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1083:
--

Github user afs commented on the pull request:

https://github.com/apache/jena/pull/106#issuecomment-163886614
  
The whitespace changes make it tricky to follow the real changes so I have 
converted all the file in the package in master from tabs to spaces to give a 
common reference point.



> MInor refactoring in TupleTables
> 
>
> Key: JENA-1083
> URL: https://issues.apache.org/jira/browse/JENA-1083
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ
>Reporter: A. Soroka
>Priority: Minor
>
> There are some minor refactorings available for TupleTable and its subtypes, 
> particularly PMapTripleTable and PMapQuadTable that will clarify their use. 
> Specifically, current impls of those abstract types have to override several 
> methods for adding, removing, and finding tuples. In fact, the only 
> information being added when those methods are overridden is conversion 
> between canonical and internal tuple ordering. This refactoring is to provide 
> methods that do that conversion and nothing else, which will make two methods 
> the most that any implementation of those abstract classes will have to 
> provide.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] jena pull request: JENA-1083: Refactoring in TupleTable and subtyp...

[afs]

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

https://github.com/apache/jena/pull/106#discussion_r47336271
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/sparql/core/mem/QuadTableForm.java ---
@@ -124,31 +96,21 @@ public PMapQuadTable get() {
return new PMapQuadTable(name()) {
 
@Override
-   protected Quad quad(final Node s, final Node p, 
final Node o, final Node g) {
-   return Quad.create(g, s, p, o);
-   }
+public Quad tuple(final Quad q) {
+return create(q.getSubject(), q.getPredicate(), 
q.getObject(), q.getGraph());
--- End diff --

It'll be clear when the white space is standardised but am I right in 
seeing:

* Using Quad and putting strange things in the slots which is very 
confusing. `getGraph` returns the `getSubject`.
* There seems to be some creating objects just to take them apart again. 
The strength of the design is that quads/triples are not stored, instead nodes 
are placed in indexes. To reflect that, operations based on g/s/p/o in some 
order are clearer to me at least as well as reducing object churn.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-1083) MInor refactoring in TupleTables

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1083:
--

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

https://github.com/apache/jena/pull/106#discussion_r47336271
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/sparql/core/mem/QuadTableForm.java ---
@@ -124,31 +96,21 @@ public PMapQuadTable get() {
return new PMapQuadTable(name()) {
 
@Override
-   protected Quad quad(final Node s, final Node p, 
final Node o, final Node g) {
-   return Quad.create(g, s, p, o);
-   }
+public Quad tuple(final Quad q) {
+return create(q.getSubject(), q.getPredicate(), 
q.getObject(), q.getGraph());
--- End diff --

It'll be clear when the white space is standardised but am I right in 
seeing:

* Using Quad and putting strange things in the slots which is very 
confusing. `getGraph` returns the `getSubject`.
* There seems to be some creating objects just to take them apart again. 
The strength of the design is that quads/triples are not stored, instead nodes 
are placed in indexes. To reflect that, operations based on g/s/p/o in some 
order are clearer to me at least as well as reducing object churn.


> MInor refactoring in TupleTables
> 
>
> Key: JENA-1083
> URL: https://issues.apache.org/jira/browse/JENA-1083
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ
>Reporter: A. Soroka
>Priority: Minor
>
> There are some minor refactorings available for TupleTable and its subtypes, 
> particularly PMapTripleTable and PMapQuadTable that will clarify their use. 
> Specifically, current impls of those abstract types have to override several 
> methods for adding, removing, and finding tuples. In fact, the only 
> information being added when those methods are overridden is conversion 
> between canonical and internal tuple ordering. This refactoring is to provide 
> methods that do that conversion and nothing else, which will make two methods 
> the most that any implementation of those abstract classes will have to 
> provide.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Jena 3.0.1 and Fuseki 2.3.1

[Bruno P. Kinoshita]

+1 binding
Build successful with
Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06; 
2015-04-22T23:57:37+12:00)Maven home: /opt/apache-maven-3.3.3Java version: 
1.8.0_66, vendor: Oracle CorporationJava home: 
/usr/lib/jvm/java-8-oracle/jreDefault locale: en_NZ, platform encoding: UTF-8OS 
name: "linux", version: "3.16.0-50-generic", arch: "amd64", family: "unix"
and
Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06; 
2015-04-22T23:57:37+12:00)Maven home: /usr/local/Cellar/maven/3.3.3/libexecJava 
version: 1.8.0_60, vendor: Oracle CorporationJava home: 
/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jreDefault 
locale: en_US, platform encoding: UTF-8OS name: "mac os x", version: "10.10.5", 
arch: "x86_64", family: "mac"
and
Apache Maven 3.0.5Maven home: /usr/share/mavenJava version: 1.8.0_66, vendor: 
Oracle CorporationJava home: /usr/lib/jvm/java-8-oracle/jreDefault locale: 
en_NZ, platform encoding: UTF-8OS name: "linux", version: "3.19.0-39-generic", 
arch: "amd64", family: "unix"
Grabbed fuseki war from the last environment build, and deployed to an Apache 
Tomcat 9.0.0.M1 (also in Ubuntu 14.04.3 LTS server, with Java 8) and it worked 
fine. Tried connecting SKOSMOS, but had some problems related to SKOSMOS and my 
Ubuntu + PHP 5.5.
Everything seems to be working correctly. Executed some code that was doing 
some basic RDF in Java, and everything is looking good. Also tried created an 
in-memory dataset and it also worked with no problems.
Thanks a lot for the hard work, and sorry for not being of much help in the 
last months :o) Will play more with the new version once it is released, and 
will review the documentation, in special Jena Text, Jena Permissions and Jena 
Elephas, as I think I will use these modules in a POC in the next weeks.
CheersBruno


  From: Andy Seaborne 
 To: dev@jena.apache.org 
 Sent: Wednesday, 9 December 2015 12:56 AM
 Subject: [VOTE] Release Jena 3.0.1 and Fuseki 2.3.1
  
Hi,

Here is a vote on a release of Jena 3.0.1 with Fuseki 2.3.1 and Fuseki
1.3.1.

This is the first proposed candidate for this release.

It includes:

* In-memory txn dataset RC (Adam Soroka)

http://jena.staging.apache.org/documentation/rdf/datasets.html

* Quads (Qihong Lin)

http://jena.staging.apache.org/documentation/query/construct-quad.html

* configurable lucene analyzers (Osma Suominen)

http://jena.staging.apache.org/documentation/query/text-query.html#configuring-an-analyzer

* Improved start-up and configuration to wire the jars together
  and other code can join in.

* general maintenance: about 74 JIRA.

Dependency changes:

Added:
com.github.andrewoma.dexx::dexx-collections:0.2

(for testing)
com.jayway.awaitility:awaitility:1.6.4

Updates:
jsonld-java : 0.5.1 -> 0.7.0
httpcore 4.2.5 -> 4.2.6




Everyone, not just committers, is invited to test and vote.

Staging repository:
https://repository.apache.org/content/repositories/orgapachejena-1010/

Proposed dist/ area:
    https://dist.apache.org/repos/dist/dev/jena/

Keys:
    https://svn.apache.org/repos/asf/jena/dist/KEYS

Git commit (browser URL):
    http://git-wip-us.apache.org/repos/asf/jena/commit/499317ad

Git Commit Hash:
    499317adff7902195ae4fa87254d6c176b6fb1d6

Git Commit Tag:
    jena-3.0.1-rc1

Please vote to approve this release:

    [ ] +1 Approve the release
    [ ]  0 Don't care
    [ ] -1 Don't release, because ...

This vote will be open to at least the end of

    Friday, 11th December 2015, 23:59 UTC

(72 hours from the same hour tonight UTC).

If you expect to check the release but the 72 hour limit does not work 
for you, please email within the schedule above with an expected time 
and we can extend the vote period.

Thanks,

    Andy

Checking needed:

+ does everything work on Linux?
+ does everything work on MS Windows?
+ does everything work on OS X?
+ are the GPG signatures fine?
+ are the checksums correct?
+ is there a source archive?
+ can the source archive really be built?
+ is there a correct LICENSE and NOTICE file in each artifact
      (both source and binary artifacts)?
+ does the NOTICE file contain all necessary attributions?
+ have any licenses of dependencies changed due to upgrades?
        if so have LICENSE and NOTICE been upgraded appropriately?
+ does the tag/commit in the SCM contain reproducible sources?


   

Re: [] Release Jena 3.0.1 and Fuseki 2.3.1

[Andy Seaborne]

On 10/12/15 20:18, Osma Suominen wrote:

PREFIX skos: 
PREFIX text: 

SELECT *
WHERE {
   GRAPH  {
 GRAPH   {
   (?s ?score ?literal) text:query 'musiikkikasv*' .
 }
 ?s skos:prefLabel ?label .
 FILTER (LANG(?label)=LANG(?literal))
   }
}


You are running with union default graph? In which case that's good.

Else use 

One of my regrets in SPARQL is that you can't get back to the default 
graph inside a GRAPH block.


The key to your query is the back that the FILTER covers the inner GRAPH.

This should work:

WHERE {
   (?s ?score ?literal) text:query 'musiikkikasv*' .
   GRAPH  { ?s skos:prefLabel ?label . }
   FILTER (LANG(?label)=LANG(?literal))
}

and it gets optimized into a

You had an OPTIONAL in the original:

WHERE {
(?s ?score ?literal) text:query 'musiikkikasv*' .
OPTIONAL {
GRAPH 
{ ?s skos:prefLabel ?label . }
}
FILTER (!BOUND(?label) || LANG(?label)=LANG(?literal))
}

or

WHERE {
(?s ?score ?literal) text:query 'musiikkikasv*' .
   OPTIONAL {
 GRAPH 
  { ?s skos:prefLabel ?label . }
 FILTER (LANG(?label)=LANG(?literal))
   }
}

In this one it is very important the FILTER is at the top level of the 
OPTIONAL{} block.  It puts ?literal in-scope because the FILTER is part 
of the LeftJoin condition.


Andy

Re: [] Release Jena 3.0.1 and Fuseki 2.3.1

[Osma Suominen]

Hi Andy!

On 11/12/15 13:54, Andy Seaborne wrote:

On 10/12/15 20:18, Osma Suominen wrote:

PREFIX skos: 
PREFIX text: 

SELECT *
WHERE {
   GRAPH  {
 GRAPH   {
   (?s ?score ?literal) text:query 'musiikkikasv*' .
 }
 ?s skos:prefLabel ?label .
 FILTER (LANG(?label)=LANG(?literal))
   }
}


You are running with union default graph? In which case that's good.


Yes, I'm using unionDefaultGraph=true.


Else use 


Right.


One of my regrets in SPARQL is that you can't get back to the default
graph inside a GRAPH block.


Exactly. That's the problem here, and the workaround requires using 
these magic ARQ graph names. Or...



The key to your query is the back that the FILTER covers the inner GRAPH.

This should work:

WHERE {
(?s ?score ?literal) text:query 'musiikkikasv*' .
GRAPH  { ?s skos:prefLabel ?label . }
FILTER (LANG(?label)=LANG(?literal))
}

and it gets optimized into a


...something missing from your sentence?

Indeed, this works. It's also faster than I expected (20ms). It appears 
that when the expression within the GRAPH block gets executed, ?s is 
already bound to a single resource (as returned by text:query). 
Otherwise the { ?s skos:prefLabel ?label } pattern would have to iterate 
over many potential solutions, which would have taken more time.



You had an OPTIONAL in the original:

WHERE {
 (?s ?score ?literal) text:query 'musiikkikasv*' .
 OPTIONAL {
 GRAPH 
 { ?s skos:prefLabel ?label . }
 }
 FILTER (!BOUND(?label) || LANG(?label)=LANG(?literal))
}

or

WHERE {
(?s ?score ?literal) text:query 'musiikkikasv*' .
OPTIONAL {
  GRAPH 
   { ?s skos:prefLabel ?label . }
  FILTER (LANG(?label)=LANG(?literal))
}
}

In this one it is very important the FILTER is at the top level of the
OPTIONAL{} block.  It puts ?literal in-scope because the FILTER is part
of the LeftJoin condition.


I see - moving the FILTER is indeed the key. I don't quite understand 
all the magic that's happening here, but I think I can use this to get a 
working solution.


Thanks a lot for all the explanations and help!

-Osma


--
Osma Suominen
D.Sc. (Tech), Information Systems Specialist
National Library of Finland
P.O. Box 26 (Kaikukatu 4)
00014 HELSINGIN YLIOPISTO
Tel. +358 50 3199529
osma.suomi...@helsinki.fi
http://www.nationallibrary.fi

Re: [] Release Jena 3.0.1 and Fuseki 2.3.1

[Andy Seaborne]

On 11/12/15 12:07, Osma Suominen wrote:

Hi Andy!

On 11/12/15 13:54, Andy Seaborne wrote:

On 10/12/15 20:18, Osma Suominen wrote:

PREFIX skos: 
PREFIX text: 

SELECT *
WHERE {
   GRAPH  {
 GRAPH   {
   (?s ?score ?literal) text:query 'musiikkikasv*' .
 }
 ?s skos:prefLabel ?label .
 FILTER (LANG(?label)=LANG(?literal))
   }
}


You are running with union default graph? In which case that's good.


Yes, I'm using unionDefaultGraph=true.


Else use 


Right.


One of my regrets in SPARQL is that you can't get back to the default
graph inside a GRAPH block.


Exactly. That's the problem here, and the workaround requires using
these magic ARQ graph names. Or...


The key to your query is the back that the FILTER covers the inner GRAPH.

This should work:

WHERE {
(?s ?score ?literal) text:query 'musiikkikasv*' .
GRAPH  { ?s skos:prefLabel ?label . }
FILTER (LANG(?label)=LANG(?literal))
}

and it gets optimized into a


...something missing from your sentence?


gets optimized into a stream execution.



Indeed, this works. It's also faster than I expected (20ms). It appears
that when the expression within the GRAPH block gets executed, ?s is
already bound to a single resource (as returned by text:query).
Otherwise the { ?s skos:prefLabel ?label } pattern would have to iterate
over many potential solutions, which would have taken more time.


which is why it hits the GRAPH with ?s bound.

What the optimizer has done is notice that the bottom up execution (the 
correct form) has the same output as streaming.  That FILTER inside the 
GRAPH would block that because streaming changes variable scope - the 
?literal in this case.


In the algebra from qoarse look for "sequence" (joins does index join, 
global scope variables) and "conditional" (same, expect leftjoins).





You had an OPTIONAL in the original:

WHERE {
 (?s ?score ?literal) text:query 'musiikkikasv*' .
 OPTIONAL {
 GRAPH 
 { ?s skos:prefLabel ?label . }
 }
 FILTER (!BOUND(?label) || LANG(?label)=LANG(?literal))
}

or

WHERE {
(?s ?score ?literal) text:query 'musiikkikasv*' .
OPTIONAL {
  GRAPH 
   { ?s skos:prefLabel ?label . }
  FILTER (LANG(?label)=LANG(?literal))
}
}

In this one it is very important the FILTER is at the top level of the
OPTIONAL{} block.  It puts ?literal in-scope because the FILTER is part
of the LeftJoin condition.


I see - moving the FILTER is indeed the key. I don't quite understand
all the magic that's happening here, but I think I can use this to get a
working solution.

Thanks a lot for all the explanations and help!


Glad to help,

We still have that weird "graph" getting redefined which is most odd.

Back to the release ...

You retracted your -1 ... if you have time (and we're all short of 
that!), could say what your vote is now with a [VOTE] message.


Andy



-Osma

[GitHub] jena pull request: JENA-1083: Refactoring in TupleTable and subtyp...

[ajs6f]

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

https://github.com/apache/jena/pull/106#discussion_r47353822
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/sparql/core/mem/QuadTableForm.java ---
@@ -124,31 +96,21 @@ public PMapQuadTable get() {
return new PMapQuadTable(name()) {
 
@Override
-   protected Quad quad(final Node s, final Node p, 
final Node o, final Node g) {
-   return Quad.create(g, s, p, o);
-   }
+public Quad tuple(final Quad q) {
+return create(q.getSubject(), q.getPredicate(), 
q.getObject(), q.getGraph());
--- End diff --

These criticisms are sadly accurate. I seem to have improved in one way by 
creating other defects. I'm going to close this PR and see if I can solve the 
problems I identified (repeated code, unclear responsibility) in a better, 
tighter way, perhaps involving `ColumnMap`.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-1083) MInor refactoring in TupleTables

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1083:
--

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

https://github.com/apache/jena/pull/106#discussion_r47353822
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/sparql/core/mem/QuadTableForm.java ---
@@ -124,31 +96,21 @@ public PMapQuadTable get() {
return new PMapQuadTable(name()) {
 
@Override
-   protected Quad quad(final Node s, final Node p, 
final Node o, final Node g) {
-   return Quad.create(g, s, p, o);
-   }
+public Quad tuple(final Quad q) {
+return create(q.getSubject(), q.getPredicate(), 
q.getObject(), q.getGraph());
--- End diff --

These criticisms are sadly accurate. I seem to have improved in one way by 
creating other defects. I'm going to close this PR and see if I can solve the 
problems I identified (repeated code, unclear responsibility) in a better, 
tighter way, perhaps involving `ColumnMap`.


> MInor refactoring in TupleTables
> 
>
> Key: JENA-1083
> URL: https://issues.apache.org/jira/browse/JENA-1083
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ
>Reporter: A. Soroka
>Priority: Minor
>
> There are some minor refactorings available for TupleTable and its subtypes, 
> particularly PMapTripleTable and PMapQuadTable that will clarify their use. 
> Specifically, current impls of those abstract types have to override several 
> methods for adding, removing, and finding tuples. In fact, the only 
> information being added when those methods are overridden is conversion 
> between canonical and internal tuple ordering. This refactoring is to provide 
> methods that do that conversion and nothing else, which will make two methods 
> the most that any implementation of those abstract classes will have to 
> provide.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-1083) MInor refactoring in TupleTables

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1083:
--

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

https://github.com/apache/jena/pull/106#discussion_r47353899
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/sparql/core/mem/QuadTableForm.java ---
@@ -124,31 +96,21 @@ public PMapQuadTable get() {
return new PMapQuadTable(name()) {
 
@Override
-   protected Quad quad(final Node s, final Node p, 
final Node o, final Node g) {
-   return Quad.create(g, s, p, o);
-   }
+public Quad tuple(final Quad q) {
+return create(q.getSubject(), q.getPredicate(), 
q.getObject(), q.getGraph());
--- End diff --

To be clear, I will send that next PR in the next few days.


> MInor refactoring in TupleTables
> 
>
> Key: JENA-1083
> URL: https://issues.apache.org/jira/browse/JENA-1083
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ
>Reporter: A. Soroka
>Priority: Minor
>
> There are some minor refactorings available for TupleTable and its subtypes, 
> particularly PMapTripleTable and PMapQuadTable that will clarify their use. 
> Specifically, current impls of those abstract types have to override several 
> methods for adding, removing, and finding tuples. In fact, the only 
> information being added when those methods are overridden is conversion 
> between canonical and internal tuple ordering. This refactoring is to provide 
> methods that do that conversion and nothing else, which will make two methods 
> the most that any implementation of those abstract classes will have to 
> provide.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] jena pull request: JENA-1083: Refactoring in TupleTable and subtyp...

[ajs6f]

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

https://github.com/apache/jena/pull/106#discussion_r47353899
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/sparql/core/mem/QuadTableForm.java ---
@@ -124,31 +96,21 @@ public PMapQuadTable get() {
return new PMapQuadTable(name()) {
 
@Override
-   protected Quad quad(final Node s, final Node p, 
final Node o, final Node g) {
-   return Quad.create(g, s, p, o);
-   }
+public Quad tuple(final Quad q) {
+return create(q.getSubject(), q.getPredicate(), 
q.getObject(), q.getGraph());
--- End diff --

To be clear, I will send that next PR in the next few days.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] jena pull request: JENA-1083: Refactoring in TupleTable and subtyp...

[ajs6f]

Github user ajs6f closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-1083) MInor refactoring in TupleTables

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1083:
--

Github user ajs6f closed the pull request at:

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


> MInor refactoring in TupleTables
> 
>
> Key: JENA-1083
> URL: https://issues.apache.org/jira/browse/JENA-1083
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ
>Reporter: A. Soroka
>Priority: Minor
>
> There are some minor refactorings available for TupleTable and its subtypes, 
> particularly PMapTripleTable and PMapQuadTable that will clarify their use. 
> Specifically, current impls of those abstract types have to override several 
> methods for adding, removing, and finding tuples. In fact, the only 
> information being added when those methods are overridden is conversion 
> between canonical and internal tuple ordering. This refactoring is to provide 
> methods that do that conversion and nothing else, which will make two methods 
> the most that any implementation of those abstract classes will have to 
> provide.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] jena pull request: JENA-1083: Refactoring in TupleTable and subtyp...

[afs]

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

https://github.com/apache/jena/pull/106#discussion_r47354583
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/sparql/core/mem/QuadTableForm.java ---
@@ -124,31 +96,21 @@ public PMapQuadTable get() {
return new PMapQuadTable(name()) {
 
@Override
-   protected Quad quad(final Node s, final Node p, 
final Node o, final Node g) {
-   return Quad.create(g, s, p, o);
-   }
+public Quad tuple(final Quad q) {
+return create(q.getSubject(), q.getPredicate(), 
q.getObject(), q.getGraph());
--- End diff --

We have time. The release build for the vote has already been done.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-1083) MInor refactoring in TupleTables

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1083:
--

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

https://github.com/apache/jena/pull/106#discussion_r47354583
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/sparql/core/mem/QuadTableForm.java ---
@@ -124,31 +96,21 @@ public PMapQuadTable get() {
return new PMapQuadTable(name()) {
 
@Override
-   protected Quad quad(final Node s, final Node p, 
final Node o, final Node g) {
-   return Quad.create(g, s, p, o);
-   }
+public Quad tuple(final Quad q) {
+return create(q.getSubject(), q.getPredicate(), 
q.getObject(), q.getGraph());
--- End diff --

We have time. The release build for the vote has already been done.




> MInor refactoring in TupleTables
> 
>
> Key: JENA-1083
> URL: https://issues.apache.org/jira/browse/JENA-1083
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ
>Reporter: A. Soroka
>Priority: Minor
>
> There are some minor refactorings available for TupleTable and its subtypes, 
> particularly PMapTripleTable and PMapQuadTable that will clarify their use. 
> Specifically, current impls of those abstract types have to override several 
> methods for adding, removing, and finding tuples. In fact, the only 
> information being added when those methods are overridden is conversion 
> between canonical and internal tuple ordering. This refactoring is to provide 
> methods that do that conversion and nothing else, which will make two methods 
> the most that any implementation of those abstract classes will have to 
> provide.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] jena pull request: JENA-1078: Logging warning when transaction is ...

[afs]

Github user afs commented on the pull request:

https://github.com/apache/jena/pull/105#issuecomment-163936807
  
This causes about 12 warnings from the test suite (Eclipse and maven).

Please do add tests and check the test suite runs.  I will check them and 
fix or silence each one but it would be nice to be at least notified that it 
would happen.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-1078) TxnMem does not log a warning when commit() omitted.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1078:
--

Github user afs commented on the pull request:

https://github.com/apache/jena/pull/105#issuecomment-163936807
  
This causes about 12 warnings from the test suite (Eclipse and maven).

Please do add tests and check the test suite runs.  I will check them and 
fix or silence each one but it would be nice to be at least notified that it 
would happen.


> TxnMem does not log a warning when commit() omitted.
> 
>
> Key: JENA-1078
> URL: https://issues.apache.org/jira/browse/JENA-1078
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.0.1
>Reporter: Andy Seaborne
>Assignee: A. Soroka
> Fix For: Jena 3.1.0
>
>
> Example:
> {noformat}
>   Dataset ds = DatasetFactory.createTxnMem() ;
>   //Dataset ds = TDBFactory.createDataset() ;
>   ds.begin(ReadWrite.WRITE) ;
>   //ds.commit();
>   ds.end() ;
> {noformat}
> whereas a read transaction can be:
> {noformat}
>   Dataset ds = DatasetFactory.createTxnMem() ;
>   ds.begin(ReadWrite.READ) ;
>   ds.end() ;
> {noformat}
> See javadoc for {{org.apache.jena.sparql.core.Transactional}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] jena pull request: JENA-1078: Logging warning when transaction is ...

[ajs6f]

Github user ajs6f commented on the pull request:

https://github.com/apache/jena/pull/105#issuecomment-163937760
  
I had no idea that throwing WARNINGs in the test suite was any kind of 
issue. ERRORs, yes, but not WARNINGs. That's a policy that might be recorded 
somewhere, perhaps 
[here](https://jena.apache.org/getting_involved/reviewing_contributions.html)?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-1078) TxnMem does not log a warning when commit() omitted.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1078:
--

Github user ajs6f commented on the pull request:

https://github.com/apache/jena/pull/105#issuecomment-163937760
  
I had no idea that throwing WARNINGs in the test suite was any kind of 
issue. ERRORs, yes, but not WARNINGs. That's a policy that might be recorded 
somewhere, perhaps 
[here](https://jena.apache.org/getting_involved/reviewing_contributions.html)?


> TxnMem does not log a warning when commit() omitted.
> 
>
> Key: JENA-1078
> URL: https://issues.apache.org/jira/browse/JENA-1078
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.0.1
>Reporter: Andy Seaborne
>Assignee: A. Soroka
> Fix For: Jena 3.1.0
>
>
> Example:
> {noformat}
>   Dataset ds = DatasetFactory.createTxnMem() ;
>   //Dataset ds = TDBFactory.createDataset() ;
>   ds.begin(ReadWrite.WRITE) ;
>   //ds.commit();
>   ds.end() ;
> {noformat}
> whereas a read transaction can be:
> {noformat}
>   Dataset ds = DatasetFactory.createTxnMem() ;
>   ds.begin(ReadWrite.READ) ;
>   ds.end() ;
> {noformat}
> See javadoc for {{org.apache.jena.sparql.core.Transactional}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] jena pull request: JENA-1078: Logging warning when transaction is ...

[ajs6f]

Github user ajs6f commented on the pull request:

https://github.com/apache/jena/pull/105#issuecomment-163938075
  
 In any event, I can review them and eliminate them. No need for you to 
spend time doing that-- this is my code and I take responsibility for it. Would 
you reopen the ticket for me?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-1078) TxnMem does not log a warning when commit() omitted.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1078:
--

Github user ajs6f commented on the pull request:

https://github.com/apache/jena/pull/105#issuecomment-163938075
  
 In any event, I can review them and eliminate them. No need for you to 
spend time doing that-- this is my code and I take responsibility for it. Would 
you reopen the ticket for me?


> TxnMem does not log a warning when commit() omitted.
> 
>
> Key: JENA-1078
> URL: https://issues.apache.org/jira/browse/JENA-1078
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.0.1
>Reporter: Andy Seaborne
>Assignee: A. Soroka
> Fix For: Jena 3.1.0
>
>
> Example:
> {noformat}
>   Dataset ds = DatasetFactory.createTxnMem() ;
>   //Dataset ds = TDBFactory.createDataset() ;
>   ds.begin(ReadWrite.WRITE) ;
>   //ds.commit();
>   ds.end() ;
> {noformat}
> whereas a read transaction can be:
> {noformat}
>   Dataset ds = DatasetFactory.createTxnMem() ;
>   ds.begin(ReadWrite.READ) ;
>   ds.end() ;
> {noformat}
> See javadoc for {{org.apache.jena.sparql.core.Transactional}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-1082) Add to org.apache.jena.rdf.model.ModelCon interface a listLiteralStatements method that accepts ints.

[JIRA]

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

Ramiro Pereira de Magalhães commented on JENA-1082:
---

It doesn't, but I managed to do a similar query with 
{{listResourcesWithProperty}} combined with 
{{ResourceFactory.createTypedLiteral}}.

As you have already noted, this is just a request for improvement since, 
clearly, the {{listLiteralStatements}} methods are a convenience for the API 
users, but it lacks a type that is used a lot and is consistently present in 
other methods.

> Add to org.apache.jena.rdf.model.ModelCon interface a listLiteralStatements 
> method that accepts ints.
> -
>
> Key: JENA-1082
> URL: https://issues.apache.org/jira/browse/JENA-1082
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: Jena 3.0.0
>Reporter: Ramiro Pereira de Magalhães
>Priority: Minor
>
> Add to org.apache.jena.rdf.model.ModelCon interface a {{StmtIterator 
> listLiteralStatements(Resource subject, Property predicate, int object );}} 
> method.
> Implement such method in classes that implement such interface. This method 
> should be able to list literal integer statements, like the other 
> listLiteralStatement methods do to other types.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] jena pull request: JENA-1078: Logging warning when transaction is ...

[afs]

Github user afs commented on the pull request:

https://github.com/apache/jena/pull/105#issuecomment-163944788
  
We have had the discussion about warnings again on the dev@ just recently.

I've already started on a review and some fixes.  There are some other 
problems with abort/end. I will submit a PR here for detailed code review. The 
issues look harmless but that's because of the way the implementation of 
indexes happen to work.  Different plugged in indexes would not be so safe.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-1078) TxnMem does not log a warning when commit() omitted.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1078:
--

Github user afs commented on the pull request:

https://github.com/apache/jena/pull/105#issuecomment-163944788
  
We have had the discussion about warnings again on the dev@ just recently.

I've already started on a review and some fixes.  There are some other 
problems with abort/end. I will submit a PR here for detailed code review. The 
issues look harmless but that's because of the way the implementation of 
indexes happen to work.  Different plugged in indexes would not be so safe.


> TxnMem does not log a warning when commit() omitted.
> 
>
> Key: JENA-1078
> URL: https://issues.apache.org/jira/browse/JENA-1078
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.0.1
>Reporter: Andy Seaborne
>Assignee: A. Soroka
> Fix For: Jena 3.1.0
>
>
> Example:
> {noformat}
>   Dataset ds = DatasetFactory.createTxnMem() ;
>   //Dataset ds = TDBFactory.createDataset() ;
>   ds.begin(ReadWrite.WRITE) ;
>   //ds.commit();
>   ds.end() ;
> {noformat}
> whereas a read transaction can be:
> {noformat}
>   Dataset ds = DatasetFactory.createTxnMem() ;
>   ds.begin(ReadWrite.READ) ;
>   ds.end() ;
> {noformat}
> See javadoc for {{org.apache.jena.sparql.core.Transactional}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-1082) Add to org.apache.jena.rdf.model.ModelCon interface a listLiteralStatements method that accepts ints.

[Andy Seaborne (JIRA)]

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

Andy Seaborne commented on JENA-1082:
-

Please do submit patch.

I'm interested in why the {{long}} version does not work for you - it might 
affect others if we add an additional one for int as int to long promotion will 
not then occur.

Which storage layer are you using?

> Add to org.apache.jena.rdf.model.ModelCon interface a listLiteralStatements 
> method that accepts ints.
> -
>
> Key: JENA-1082
> URL: https://issues.apache.org/jira/browse/JENA-1082
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: Jena 3.0.0
>Reporter: Ramiro Pereira de Magalhães
>Priority: Minor
>
> Add to org.apache.jena.rdf.model.ModelCon interface a {{StmtIterator 
> listLiteralStatements(Resource subject, Property predicate, int object );}} 
> method.
> Implement such method in classes that implement such interface. This method 
> should be able to list literal integer statements, like the other 
> listLiteralStatement methods do to other types.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (JENA-1082) Add to org.apache.jena.rdf.model.ModelCon interface a listLiteralStatements method that accepts ints.

[Andy Seaborne (JIRA)]

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

Andy Seaborne edited comment on JENA-1082 at 12/11/15 2:23 PM:
---

Please do submit a patch or pull request.

I'm interested in why the {{long}} version does not work for you - it might 
affect others if we add an additional one for int as int to long promotion will 
not then occur.

Which storage layer are you using?


was (Author: andy.seaborne):
Please do submit patch.

I'm interested in why the {{long}} version does not work for you - it might 
affect others if we add an additional one for int as int to long promotion will 
not then occur.

Which storage layer are you using?

> Add to org.apache.jena.rdf.model.ModelCon interface a listLiteralStatements 
> method that accepts ints.
> -
>
> Key: JENA-1082
> URL: https://issues.apache.org/jira/browse/JENA-1082
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: Jena 3.0.0
>Reporter: Ramiro Pereira de Magalhães
>Priority: Minor
>
> Add to org.apache.jena.rdf.model.ModelCon interface a {{StmtIterator 
> listLiteralStatements(Resource subject, Property predicate, int object );}} 
> method.
> Implement such method in classes that implement such interface. This method 
> should be able to list literal integer statements, like the other 
> listLiteralStatement methods do to other types.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (JENA-1085) Review trasnaction finishes for DatasetGraphInMemory

[Andy Seaborne (JIRA)]

Andy Seaborne created JENA-1085:
---

 Summary: Review trasnaction finishes for DatasetGraphInMemory
 Key: JENA-1085
 URL: https://issues.apache.org/jira/browse/JENA-1085
 Project: Apache Jena
  Issue Type: Task
  Components: ARQ
Affects Versions: Jena 3.0.1
Reporter: Andy Seaborne
Assignee: Andy Seaborne
 Fix For: Jena 3.1.0


This JIRA is for a review of the transaction finishing code.

Some of the code works because of the nature of specific implementations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Jena 3.0.1 and Fuseki 2.3.1

[Osma Suominen]

On 08/12/15 13:56, Andy Seaborne wrote:

Hi,

Here is a vote on a release of Jena 3.0.1 with Fuseki 2.3.1 and Fuseki
1.3.1.


+1.

I'm still a bit worried about the weird GRAPH with VALUES error that I 
stumbled on yesterday, but it doesn't seem to affect my actual queries 
(which also combine GRAPH with text:query and VALUES but in more complex 
ways), and it's apparently not a regression from 1.3.0, so it can be 
left for later.


-Osma

--
Osma Suominen
D.Sc. (Tech), Information Systems Specialist
National Library of Finland
P.O. Box 26 (Kaikukatu 4)
00014 HELSINGIN YLIOPISTO
Tel. +358 50 3199529
osma.suomi...@helsinki.fi
http://www.nationallibrary.fi

[GitHub] jena pull request: JENA-1085 : Common pattern for passing down tra...

[afs]

GitHub user afs opened a pull request:

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

JENA-1085 : Common pattern for passing down transaction lifecycle 
operations.


* Abort called `end` directly causing the warning to be emitted
* Abort did not call quadIndex.abort/defaultGraph.abort
* Pair up quadIndex.end/defaultGraph.end for read transactions
* Add locks around all pairs of quadIndex, defaultGraph operation calls


Discussion points:

* `writeLock` is used even for read transactions (it's a no-op but it's 
called). Shoudl we rename it as e.g. `readerWriterLock`?
* `TupleTable.abort` defaults to end.  Given the importance of the 
transaction cycle, might it be better to require each implementation to do 
that. It puts all the begin/commit/abort/end code for one component in one 
place for the next person to look at the code.

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

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

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

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


commit 39af9c3b447b56c2f237af43c0b5ffb5fa287bce
Author: Andy Seaborne 
Date:   2015-12-11T14:28:48Z

Cleanly abort a write transaction.

commit c709ef793bf2f99e8ed951e67509679a36f6af7b
Author: Andy Seaborne 
Date:   2015-12-11T14:29:58Z

JENA-1078: Silence warnings.

This calls tests error conditions makign logged warnings expected.

commit 2cfa0e30aabebb069921a3187a57f17ec1d37310
Author: Andy Seaborne 
Date:   2015-12-11T14:38:07Z

JENA-1085: Always pass down transaction lifecycle calls.

* Abort called `end` directly causing the warning to be emitted
* Abort did not call quadIndex.abort/defaultGraph.abort
* Pair up quadIndex.end/defaultGraph.end for read transactions
* Add locks around all pairs of quadIndex, defaultGraph operation calls




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-1085) Review trasnaction finishes for DatasetGraphInMemory

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1085:
--

GitHub user afs opened a pull request:

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

JENA-1085 : Common pattern for passing down transaction lifecycle 
operations.


* Abort called `end` directly causing the warning to be emitted
* Abort did not call quadIndex.abort/defaultGraph.abort
* Pair up quadIndex.end/defaultGraph.end for read transactions
* Add locks around all pairs of quadIndex, defaultGraph operation calls


Discussion points:

* `writeLock` is used even for read transactions (it's a no-op but it's 
called). Shoudl we rename it as e.g. `readerWriterLock`?
* `TupleTable.abort` defaults to end.  Given the importance of the 
transaction cycle, might it be better to require each implementation to do 
that. It puts all the begin/commit/abort/end code for one component in one 
place for the next person to look at the code.

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

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

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

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


commit 39af9c3b447b56c2f237af43c0b5ffb5fa287bce
Author: Andy Seaborne 
Date:   2015-12-11T14:28:48Z

Cleanly abort a write transaction.

commit c709ef793bf2f99e8ed951e67509679a36f6af7b
Author: Andy Seaborne 
Date:   2015-12-11T14:29:58Z

JENA-1078: Silence warnings.

This calls tests error conditions makign logged warnings expected.

commit 2cfa0e30aabebb069921a3187a57f17ec1d37310
Author: Andy Seaborne 
Date:   2015-12-11T14:38:07Z

JENA-1085: Always pass down transaction lifecycle calls.

* Abort called `end` directly causing the warning to be emitted
* Abort did not call quadIndex.abort/defaultGraph.abort
* Pair up quadIndex.end/defaultGraph.end for read transactions
* Add locks around all pairs of quadIndex, defaultGraph operation calls




> Review trasnaction finishes for DatasetGraphInMemory
> 
>
> Key: JENA-1085
> URL: https://issues.apache.org/jira/browse/JENA-1085
> Project: Apache Jena
>  Issue Type: Task
>  Components: ARQ
>Affects Versions: Jena 3.0.1
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
> Fix For: Jena 3.1.0
>
>
> This JIRA is for a review of the transaction finishing code.
> Some of the code works because of the nature of specific implementations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] jena pull request: JENA-1085 : Common pattern for passing down tra...

[ajs6f]

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

https://github.com/apache/jena/pull/107#discussion_r47392305
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/sparql/core/mem/DatasetGraphInMemory.java
 ---
@@ -166,16 +179,31 @@ public void close() {
 @Override
 public void end() {
 if (isInTransaction()) {
-if (transactionType().equals(WRITE))
-log.warn("end() called for WRITE transaction without 
commit or abort having been called");
+if (transactionType().equals(WRITE)) {
+log.warn("end() called for WRITE transaction without 
commit or abort having been called causing a forced abort");
+_abort() ;
+}
+finishTransaction();
+return ;
--- End diff --

Why an "naked" `return` here?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-1085) Review trasnaction finishes for DatasetGraphInMemory

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1085:
--

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

https://github.com/apache/jena/pull/107#discussion_r47392305
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/sparql/core/mem/DatasetGraphInMemory.java
 ---
@@ -166,16 +179,31 @@ public void close() {
 @Override
 public void end() {
 if (isInTransaction()) {
-if (transactionType().equals(WRITE))
-log.warn("end() called for WRITE transaction without 
commit or abort having been called");
+if (transactionType().equals(WRITE)) {
+log.warn("end() called for WRITE transaction without 
commit or abort having been called causing a forced abort");
+_abort() ;
+}
+finishTransaction();
+return ;
--- End diff --

Why an "naked" `return` here?


> Review trasnaction finishes for DatasetGraphInMemory
> 
>
> Key: JENA-1085
> URL: https://issues.apache.org/jira/browse/JENA-1085
> Project: Apache Jena
>  Issue Type: Task
>  Components: ARQ
>Affects Versions: Jena 3.0.1
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
> Fix For: Jena 3.1.0
>
>
> This JIRA is for a review of the transaction finishing code.
> Some of the code works because of the nature of specific implementations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-1085) Review trasnaction finishes for DatasetGraphInMemory

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1085:
--

Github user ajs6f commented on the pull request:

https://github.com/apache/jena/pull/107#issuecomment-164023587
  
Yes, I think that renaming `writeLock` makes sense. The alternative would 
be to actually check the type of transaction and avoid fiddling with that lock 
if it is a READ. I think either is okay and either is clearer than what is 
there now.


> Review trasnaction finishes for DatasetGraphInMemory
> 
>
> Key: JENA-1085
> URL: https://issues.apache.org/jira/browse/JENA-1085
> Project: Apache Jena
>  Issue Type: Task
>  Components: ARQ
>Affects Versions: Jena 3.0.1
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
> Fix For: Jena 3.1.0
>
>
> This JIRA is for a review of the transaction finishing code.
> Some of the code works because of the nature of specific implementations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] jena pull request: JENA-1085 : Common pattern for passing down tra...

[ajs6f]

Github user ajs6f commented on the pull request:

https://github.com/apache/jena/pull/107#issuecomment-164023587
  
Yes, I think that renaming `writeLock` makes sense. The alternative would 
be to actually check the type of transaction and avoid fiddling with that lock 
if it is a READ. I think either is okay and either is clearer than what is 
there now.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] jena pull request: JENA-1085 : Common pattern for passing down tra...

[ajs6f]

Github user ajs6f commented on the pull request:

https://github.com/apache/jena/pull/107#issuecomment-164023866
  
I'm fine with pulling out the default impl of `TupleTable::abort`. I myself 
don't find it any less clear, but if you do, that's evidence enough.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-1085) Review trasnaction finishes for DatasetGraphInMemory

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1085:
--

Github user ajs6f commented on the pull request:

https://github.com/apache/jena/pull/107#issuecomment-164023866
  
I'm fine with pulling out the default impl of `TupleTable::abort`. I myself 
don't find it any less clear, but if you do, that's evidence enough.


> Review trasnaction finishes for DatasetGraphInMemory
> 
>
> Key: JENA-1085
> URL: https://issues.apache.org/jira/browse/JENA-1085
> Project: Apache Jena
>  Issue Type: Task
>  Components: ARQ
>Affects Versions: Jena 3.0.1
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
> Fix For: Jena 3.1.0
>
>
> This JIRA is for a review of the transaction finishing code.
> Some of the code works because of the nature of specific implementations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JENA-1085) Review transaction finishes for DatasetGraphInMemory

[Andy Seaborne (JIRA)]

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

Andy Seaborne updated JENA-1085:

Summary: Review transaction finishes for DatasetGraphInMemory  (was: Review 
trasnaction finishes for DatasetGraphInMemory)

> Review transaction finishes for DatasetGraphInMemory
> 
>
> Key: JENA-1085
> URL: https://issues.apache.org/jira/browse/JENA-1085
> Project: Apache Jena
>  Issue Type: Task
>  Components: ARQ
>Affects Versions: Jena 3.0.1
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
> Fix For: Jena 3.1.0
>
>
> This JIRA is for a review of the transaction finishing code.
> Some of the code works because of the nature of specific implementations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-1081) Turtle writer does not inline blank node in lists.

[ASF subversion and git services (JIRA)]

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

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

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

JENA-1081: Improve Turtle pretty layout for blank nodes in lists.



> Turtle writer does not inline blank node in lists.
> --
>
> Key: JENA-1081
> URL: https://issues.apache.org/jira/browse/JENA-1081
> Project: Apache Jena
>  Issue Type: Bug
>  Components: RIOT, T
>Affects Versions: Jena 3.1.0
>Reporter: Andy Seaborne
>Priority: Minor
>
> {noformat}
> prefix : 
> :s :p ( [:q 1] [:q 2]) .
> {noformat}
> ==>
> {noformat}
> @prefix :   .
> :s  :p  ( _:b0 _:b1 ) .
> _:b0:q  1 .
> _:b1:q  2 .
> {noformat}
> if enabled (remove lines in {{TurtleShell.ShellGraph.findBNodesSyntax1}}, the 
> list is badly formatted.
> # Multiproperty elements use {{] [}} at end of each so the formatter indents 
> by 2 per element.
> # Mixed short (one property) and long (>1 property) {{[ ]}} looks bad because 
> the short form is one line.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (JENA-1081) Turtle writer does not inline blank node in lists.

[Andy Seaborne (JIRA)]

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

Andy Seaborne resolved JENA-1081.
-
   Resolution: Fixed
 Assignee: Andy Seaborne
Fix Version/s: Jena 3.1.0

> Turtle writer does not inline blank node in lists.
> --
>
> Key: JENA-1081
> URL: https://issues.apache.org/jira/browse/JENA-1081
> Project: Apache Jena
>  Issue Type: Bug
>  Components: RIOT, T
>Affects Versions: Jena 3.1.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.1.0
>
>
> {noformat}
> prefix : 
> :s :p ( [:q 1] [:q 2]) .
> {noformat}
> ==>
> {noformat}
> @prefix :   .
> :s  :p  ( _:b0 _:b1 ) .
> _:b0:q  1 .
> _:b1:q  2 .
> {noformat}
> if enabled (remove lines in {{TurtleShell.ShellGraph.findBNodesSyntax1}}, the 
> list is badly formatted.
> # Multiproperty elements use {{] [}} at end of each so the formatter indents 
> by 2 per element.
> # Mixed short (one property) and long (>1 property) {{[ ]}} looks bad because 
> the short form is one line.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-1080) Fuseki Web Interface incompatible with Internet Explorer

[Andy Seaborne (JIRA)]

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

Andy Seaborne commented on JENA-1080:
-

(Not being an IE 11 user)

Is there anything we can do to make IE11 render it in "Edge" mode?

> Fuseki Web Interface incompatible with Internet Explorer
> 
>
> Key: JENA-1080
> URL: https://issues.apache.org/jira/browse/JENA-1080
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Fuseki
>Affects Versions: Fuseki 2.3.0
> Environment: Microsoft Internet Explorer 11.0.9600.18097
>Reporter: Donald Pellegrino
>Priority: Trivial
>  Labels: windows
>
> Microsoft Internet Explorer 11 defaults to rendering Apache Jena Fuseki web 
> pages in "Document mode 7." Using F12 and manually changing the "Document 
> mode" to "Edge" seems to work-around the problem.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (JENA-1086) property functions block filter placement.

[Andy Seaborne (JIRA)]

Andy Seaborne created JENA-1086:
---

 Summary: property functions block filter placement.
 Key: JENA-1086
 URL: https://issues.apache.org/jira/browse/JENA-1086
 Project: Apache Jena
  Issue Type: Improvement
  Components: ARQ
Affects Versions: Jena 3.0.1
Reporter: Andy Seaborne


There is no reason that this filter can't be pushed through the property 
function.

Output of {{qparse --print=query --print=opt}}

{noformat}
PREFIX  : 
PREFIX  list: 

SELECT  *
WHERE
  { ?s :p   ?o .
?list  list:member  ?member
FILTER ( ?o )
  }
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(prefix ((: )
 (list: ))
  (filter ?o
(propfunc list:member
  ?list ?member
  (bgp (triple ?s :p ?o)
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-1036) "add new dataset" function is not working in WebUI

[Bruno P. Kinoshita (JIRA)]

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

Bruno P. Kinoshita commented on JENA-1036:
--

Seems to be working fine for me. +1 to close it.

> "add new dataset" function is not working in WebUI
> --
>
> Key: JENA-1036
> URL: https://issues.apache.org/jira/browse/JENA-1036
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Affects Versions: Fuseki 2.3.0
> Environment: Chrome
>Reporter: Mirko Kaempf
>
> The WebUI on default port 3030 shows some menus. The loaded data is also 
> available and simple queries from CLI work, but the WebUI does not work.
> No error message is shown.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (JENA-1087) Fix minor code warnings such as deprecated methods, typos in comments and missing serial version UID fields

[Bruno P. Kinoshita (JIRA)]

Bruno P. Kinoshita created JENA-1087:


 Summary: Fix minor code warnings such as deprecated methods, typos 
in comments and missing serial version UID fields
 Key: JENA-1087
 URL: https://issues.apache.org/jira/browse/JENA-1087
 Project: Apache Jena
  Issue Type: Improvement
  Components: Fuseki
 Environment: Apache Maven 3.0.5
Maven home: /usr/share/maven
Java version: 1.7.0_91, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre
Default locale: en_NZ, platform encoding: UTF-8
OS name: "linux", version: "3.19.0-39-generic", arch: "amd64", family: "unix"

Ubuntu 14.04.3 LTS
Latest code from git repository.
Reporter: Bruno P. Kinoshita
Assignee: Bruno P. Kinoshita
Priority: Trivial


Reviewing Jena Fuseki 2 modules, there are few simple issues that could be 
easily fixed, such as 

* code using deprecated code, which comments suggest right alternatives (e.g. 
DatasetGraphFactory.createGeneral() instead of DatasetGraphFactory.createMem())

* code that implements Serializable but without serialVersionUID

* typos in comments

* missing Javadocs

Will try to address this issue in simple commits, with clear explanation of 
what was fixed, without changing code format or adding too many other changes; 
which would make it harder to review the changes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-1087) Fix minor code warnings such as deprecated methods, typos in comments and missing serial version UID fields

[ASF subversion and git services (JIRA)]

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

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

Commit 47d05870a1a6a071b51289d4b657972b74f0b3f5 in jena's branch 
refs/heads/master from [~kinow]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=47d0587 ]

JENA-1087: add serialVersionUID, fix typos, add comments and replace deprecated 
calls


> Fix minor code warnings such as deprecated methods, typos in comments and 
> missing serial version UID fields
> ---
>
> Key: JENA-1087
> URL: https://issues.apache.org/jira/browse/JENA-1087
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Fuseki
> Environment: Apache Maven 3.0.5
> Maven home: /usr/share/maven
> Java version: 1.7.0_91, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre
> Default locale: en_NZ, platform encoding: UTF-8
> OS name: "linux", version: "3.19.0-39-generic", arch: "amd64", family: "unix"
> Ubuntu 14.04.3 LTS
> Latest code from git repository.
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
>  Labels: deprecated, javadoc, serialization, trivial, typo
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Reviewing Jena Fuseki 2 modules, there are few simple issues that could be 
> easily fixed, such as 
> * code using deprecated code, which comments suggest right alternatives (e.g. 
> DatasetGraphFactory.createGeneral() instead of 
> DatasetGraphFactory.createMem())
> * code that implements Serializable but without serialVersionUID
> * typos in comments
> * missing Javadocs
> Will try to address this issue in simple commits, with clear explanation of 
> what was fixed, without changing code format or adding too many other 
> changes; which would make it harder to review the changes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (JENA-1087) Fix minor code warnings such as deprecated methods, typos in comments and missing serial version UID fields

[Bruno P. Kinoshita (JIRA)]

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

Bruno P. Kinoshita resolved JENA-1087.
--
Resolution: Fixed

> Fix minor code warnings such as deprecated methods, typos in comments and 
> missing serial version UID fields
> ---
>
> Key: JENA-1087
> URL: https://issues.apache.org/jira/browse/JENA-1087
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Fuseki
> Environment: Apache Maven 3.0.5
> Maven home: /usr/share/maven
> Java version: 1.7.0_91, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre
> Default locale: en_NZ, platform encoding: UTF-8
> OS name: "linux", version: "3.19.0-39-generic", arch: "amd64", family: "unix"
> Ubuntu 14.04.3 LTS
> Latest code from git repository.
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
>  Labels: deprecated, javadoc, serialization, trivial, typo
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Reviewing Jena Fuseki 2 modules, there are few simple issues that could be 
> easily fixed, such as 
> * code using deprecated code, which comments suggest right alternatives (e.g. 
> DatasetGraphFactory.createGeneral() instead of 
> DatasetGraphFactory.createMem())
> * code that implements Serializable but without serialVersionUID
> * typos in comments
> * missing Javadocs
> Will try to address this issue in simple commits, with clear explanation of 
> what was fixed, without changing code format or adding too many other 
> changes; which would make it harder to review the changes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JENA-1088) Fuseki 2 allows duplicate datasets when using only spaces in name

[Bruno P. Kinoshita (JIRA)]

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

Bruno P. Kinoshita updated JENA-1088:
-
Labels: web  (was: )

> Fuseki 2 allows duplicate datasets when using only spaces in name
> -
>
> Key: JENA-1088
> URL: https://issues.apache.org/jira/browse/JENA-1088
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>  Labels: web
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Was testing Fuseki 2, before reviewing the docs, and decided to experiment a 
> few things. Looks like if you use just spaces in the dataset name, you are 
> allowed to create a new one, and it gets the name "/". Which is fine.
> But if you try that again with another random number of spaces, it inserts 
> another dataset with the same name.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JENA-1087) Fix minor code warnings such as deprecated methods, typos in comments and missing serial version UID fields

[Bruno P. Kinoshita (JIRA)]

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

Bruno P. Kinoshita updated JENA-1087:
-
Remaining Estimate: 2h  (was: 48h)
 Original Estimate: 2h  (was: 48h)

> Fix minor code warnings such as deprecated methods, typos in comments and 
> missing serial version UID fields
> ---
>
> Key: JENA-1087
> URL: https://issues.apache.org/jira/browse/JENA-1087
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Fuseki
> Environment: Apache Maven 3.0.5
> Maven home: /usr/share/maven
> Java version: 1.7.0_91, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre
> Default locale: en_NZ, platform encoding: UTF-8
> OS name: "linux", version: "3.19.0-39-generic", arch: "amd64", family: "unix"
> Ubuntu 14.04.3 LTS
> Latest code from git repository.
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
>  Labels: deprecated, javadoc, serialization, trivial, typo
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Reviewing Jena Fuseki 2 modules, there are few simple issues that could be 
> easily fixed, such as 
> * code using deprecated code, which comments suggest right alternatives (e.g. 
> DatasetGraphFactory.createGeneral() instead of 
> DatasetGraphFactory.createMem())
> * code that implements Serializable but without serialVersionUID
> * typos in comments
> * missing Javadocs
> Will try to address this issue in simple commits, with clear explanation of 
> what was fixed, without changing code format or adding too many other 
> changes; which would make it harder to review the changes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (JENA-1088) Fuseki 2 allows duplicate datasets when using only spaces in name

[Bruno P. Kinoshita (JIRA)]

Bruno P. Kinoshita created JENA-1088:


 Summary: Fuseki 2 allows duplicate datasets when using only spaces 
in name
 Key: JENA-1088
 URL: https://issues.apache.org/jira/browse/JENA-1088
 Project: Apache Jena
  Issue Type: Bug
  Components: Fuseki
Reporter: Bruno P. Kinoshita
Assignee: Bruno P. Kinoshita


Was testing Fuseki 2, before reviewing the docs, and decided to experiment a 
few things. Looks like if you use just spaces in the dataset name, you are 
allowed to create a new one, and it gets the name "/". Which is fine.

But if you try that again with another random number of spaces, it inserts 
another dataset with the same name.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JENA-1088) Fuseki 2 allows duplicate datasets when using only spaces in name

[Bruno P. Kinoshita (JIRA)]

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

Bruno P. Kinoshita updated JENA-1088:
-
Attachment: JENA-1088.png

Attaching screen shot.

> Fuseki 2 allows duplicate datasets when using only spaces in name
> -
>
> Key: JENA-1088
> URL: https://issues.apache.org/jira/browse/JENA-1088
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>  Labels: web
> Attachments: JENA-1088.png
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Was testing Fuseki 2, before reviewing the docs, and decided to experiment a 
> few things. Looks like if you use just spaces in the dataset name, you are 
> allowed to create a new one, and it gets the name "/". Which is fine.
> But if you try that again with another random number of spaces, it inserts 
> another dataset with the same name.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)