[jira] [Resolved] (JENA-2242) Include VALUES clause in string when stringifying a WhereBuilder

[Claude Warren (Jira)]

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

Claude Warren resolved JENA-2242.
-
Fix Version/s: Jena 4.4.0
   Resolution: Fixed

fixed by pull request 1158

> Include VALUES clause in string when stringifying a WhereBuilder
> 
>
> Key: JENA-2242
> URL: https://issues.apache.org/jira/browse/JENA-2242
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: QueryBuilder
>Affects Versions: Jena 4.3.2
>Reporter: Kelvin Qian
>Assignee: Claude Warren
>Priority: Major
> Fix For: Jena 4.4.0
>
>
> Currently when stringifying a WhereBuilder (e.g. for debugging), any VALUES 
> clause is not included in the output of .toString:
> {code:java}
> import java.util.ArrayList;
> import java.util.HashMap;
> import org.apache.jena.graph.Node;
> import org.apache.jena.grpah.Triple;
> import org.apache.jena.arq.querybuilder.Converters;
> import org.apache.jena.arq.querybuilder.WhereBuilder;
>  
> // Node creation
> Node svarNode = Converters.checkVar(NodeFactory.createVariable("s"));
> Node pvarNode = Converters.checkVar(NodeFactory.createVariable("p"));
> Node ovarNode = Converters.checkVar(NodeFactory.createVariable("o"));
> // Values map creation
> ArrayList subjColl = new ArrayList<>();
> subjColl.add(NodeFactory.createURI("http://example.org#subject;));
> HashMap> valMap = new HashMap<>();
> valMap.put(svarNode, subjColl);
> // WhereBuilder creation
> WhereBuilder wb = new WhereBuilder();
> wb.addWhere(svarNode, pvarNode, ovarNode);
> wb.addWhereValueVars(valMap);
> wb.toString();
> // WHERE { ?s ?p ?o }
> {code}
> It is only when you add the WhereBuilder to another builder, e.g. a 
> ConstructBuilder, when you are able to visualize the VALUES clause:
> {code:java}
> import org.apache.jena.arq.querybuilder.ConstructBuilder;
> ConstructBuilder cb = new ConstructBuilder();
> cb.addConstruct(new Triple(svarNode, pvarNode, ovarNode));
> cb.addWhere(wb);
> cb.toString();
> // CONSTRUCT 
> //   { 
> // ?s ?p ?o .
> //   }
> // WHERE
> //   { ?s  ?p  ?o
> // VALUES ( ?s ) { (  ) }
> //   }
> {code}
> Ideally we would like to visualize the VALUES clause by including it in the 
> result string while stringifying the WhereBuilder, not just with the 
> ConstructBuilder. This would improve the development experience by allowing 
> us to focus on debugging the WHERE clause, without having to consider the 
> containing query or update.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (JENA-2242) Include VALUES clause in string when stringifying a WhereBuilder

[Claude Warren (Jira)]

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

Claude Warren commented on JENA-2242:
-

Proposed fix in https://github.com/apache/jena/pull/1158

> Include VALUES clause in string when stringifying a WhereBuilder
> 
>
> Key: JENA-2242
> URL: https://issues.apache.org/jira/browse/JENA-2242
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: QueryBuilder
>Affects Versions: Jena 4.3.2
>Reporter: Kelvin Qian
>Assignee: Claude Warren
>Priority: Major
>
> Currently when stringifying a WhereBuilder (e.g. for debugging), any VALUES 
> clause is not included in the output of .toString:
> {code:java}
> import java.util.ArrayList;
> import java.util.HashMap;
> import org.apache.jena.graph.Node;
> import org.apache.jena.grpah.Triple;
> import org.apache.jena.arq.querybuilder.Converters;
> import org.apache.jena.arq.querybuilder.WhereBuilder;
>  
> // Node creation
> Node svarNode = Converters.checkVar(NodeFactory.createVariable("s"));
> Node pvarNode = Converters.checkVar(NodeFactory.createVariable("p"));
> Node ovarNode = Converters.checkVar(NodeFactory.createVariable("o"));
> // Values map creation
> ArrayList subjColl = new ArrayList<>();
> subjColl.add(NodeFactory.createURI("http://example.org#subject;));
> HashMap> valMap = new HashMap<>();
> valMap.put(svarNode, subjColl);
> // WhereBuilder creation
> WhereBuilder wb = new WhereBuilder();
> wb.addWhere(svarNode, pvarNode, ovarNode);
> wb.addWhereValueVars(valMap);
> wb.toString();
> // WHERE { ?s ?p ?o }
> {code}
> It is only when you add the WhereBuilder to another builder, e.g. a 
> ConstructBuilder, when you are able to visualize the VALUES clause:
> {code:java}
> import org.apache.jena.arq.querybuilder.ConstructBuilder;
> ConstructBuilder cb = new ConstructBuilder();
> cb.addConstruct(new Triple(svarNode, pvarNode, ovarNode));
> cb.addWhere(wb);
> cb.toString();
> // CONSTRUCT 
> //   { 
> // ?s ?p ?o .
> //   }
> // WHERE
> //   { ?s  ?p  ?o
> // VALUES ( ?s ) { (  ) }
> //   }
> {code}
> Ideally we would like to visualize the VALUES clause by including it in the 
> result string while stringifying the WhereBuilder, not just with the 
> ConstructBuilder. This would improve the development experience by allowing 
> us to focus on debugging the WHERE clause, without having to consider the 
> containing query or update.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Resolved] (JENA-2092) Adding SELECT * subquery to construct with the query builder causes bad query.

[Claude Warren (Jira)]

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

Claude Warren resolved JENA-2092.
-
Fix Version/s: Jena 4.2.0
   Resolution: Fixed

> Adding SELECT * subquery to construct with the query builder causes bad query.
> --
>
> Key: JENA-2092
> URL: https://issues.apache.org/jira/browse/JENA-2092
> Project: Apache Jena
>  Issue Type: Bug
>  Components: QueryBuilder
>Affects Versions: Jena 3.17.0, Jena 4.0.0
>Reporter: Andy Seaborne
>Assignee: Claude Warren
>Priority: Major
> Fix For: Jena 4.2.0
>
>
> [Report users@ 
> 2021-04-02|https://lists.apache.org/thread.html/r055920a11abc812c804945f660bed9fa091cb62c17d246f42e4810b7%40%3Cusers.jena.apache.org%3E]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (JENA-2109) Migrate Permissions to V4 and implement a soft read error

[Claude Warren (Jira)]

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

Claude Warren resolved JENA-2109.
-
Resolution: Fixed

> Migrate Permissions to V4 and implement a soft read error
> -
>
> Key: JENA-2109
> URL: https://issues.apache.org/jira/browse/JENA-2109
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Security
>Affects Versions: Jena 4.0.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Major
> Fix For: Jena 4.1.0
>
>
> JENA-2055 uncovered a difficult to process issue.
> When permissions to read an object were not granted the system simply threw 
> an ReadDeniedException however, in some cases the desired result is to return 
> an empty iterator.  For example if a secured graph is part of a union graph 
> and the user does not have full permissions on the secured graph the query 
> will abort when the first graph access is denied.
> The desired effect is to return
>  * An empty iterator in cases where an iterator is returned.
>  * False in cases where an existential flag is being checked.
>  * 0 (zero) when a count is being returned.
>  
> This change also brings the Permissions package into version 4.  Prior to 
> this change it had not been migrated.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (JENA-2109) Permissions should have a soft read error

[Claude Warren (Jira)]

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

Claude Warren updated JENA-2109:

Description: 
JENA-2055 uncovered a difficult to process issue.

When permissions to read an object were not granted the system simply threw an 
ReadDeniedException however, in some cases the desired result is to return an 
empty iterator.  For example if a secured graph is part of a union graph and 
the user does not have full permissions on the secured graph the query will 
abort when the first graph access is denied.

The desired effect is to return
 * An empty iterator in cases where an iterator is returned.
 * False in cases where an existential flag is being checked.
 * 0 (zero) when a count is being returned.

 

This change also brings the Permissions package into version 4.  Prior to this 
change it had not been migrated.

  was:
JENA-2055 uncovered a difficult to process issue.

When permissions to read an object were not granted the system simply threw an 
ReadDeniedException however, in some cases the desired result is to return an 
empty iterator.  For example if a secured graph is part of a union graph and 
the user does not have full permissions on the secured graph the query will 
abort when the first graph access is denied.

The desired effect is to return
 * An empty iterator in cases where an iterator is returned.
 * False in cases where an existential flag is being checked.
 * 0 (zero) when a count is being returned.

 


> Permissions should have a soft read error
> -
>
> Key: JENA-2109
> URL: https://issues.apache.org/jira/browse/JENA-2109
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Security
>Affects Versions: Jena 4.0.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Major
> Fix For: Jena 4.1.0
>
>
> JENA-2055 uncovered a difficult to process issue.
> When permissions to read an object were not granted the system simply threw 
> an ReadDeniedException however, in some cases the desired result is to return 
> an empty iterator.  For example if a secured graph is part of a union graph 
> and the user does not have full permissions on the secured graph the query 
> will abort when the first graph access is denied.
> The desired effect is to return
>  * An empty iterator in cases where an iterator is returned.
>  * False in cases where an existential flag is being checked.
>  * 0 (zero) when a count is being returned.
>  
> This change also brings the Permissions package into version 4.  Prior to 
> this change it had not been migrated.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (JENA-2109) Migrate Permissions to V4 and implement a soft read error

[Claude Warren (Jira)]

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

Claude Warren updated JENA-2109:

Summary: Migrate Permissions to V4 and implement a soft read error  (was: 
Permissions should have a soft read error)

> Migrate Permissions to V4 and implement a soft read error
> -
>
> Key: JENA-2109
> URL: https://issues.apache.org/jira/browse/JENA-2109
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Security
>Affects Versions: Jena 4.0.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Major
> Fix For: Jena 4.1.0
>
>
> JENA-2055 uncovered a difficult to process issue.
> When permissions to read an object were not granted the system simply threw 
> an ReadDeniedException however, in some cases the desired result is to return 
> an empty iterator.  For example if a secured graph is part of a union graph 
> and the user does not have full permissions on the secured graph the query 
> will abort when the first graph access is denied.
> The desired effect is to return
>  * An empty iterator in cases where an iterator is returned.
>  * False in cases where an existential flag is being checked.
>  * 0 (zero) when a count is being returned.
>  
> This change also brings the Permissions package into version 4.  Prior to 
> this change it had not been migrated.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (JENA-2109) Permissions should have a soft read error

[Claude Warren (Jira)]

Claude Warren created JENA-2109:
---

 Summary: Permissions should have a soft read error
 Key: JENA-2109
 URL: https://issues.apache.org/jira/browse/JENA-2109
 Project: Apache Jena
  Issue Type: Bug
  Components: Security
Affects Versions: Jena 4.0.0
Reporter: Claude Warren
Assignee: Claude Warren
 Fix For: Jena 4.1.0


JENA-2055 uncovered a difficult to process issue.

When permissions to read an object were not granted the system simply threw an 
ReadDeniedException however, in some cases the desired result is to return an 
empty iterator.  For example if a secured graph is part of a union graph and 
the user does not have full permissions on the secured graph the query will 
abort when the first graph access is denied.

The desired effect is to return
 * An empty iterator in cases where an iterator is returned.
 * False in cases where an existential flag is being checked.
 * 0 (zero) when a count is being returned.

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (JENA-2075) Seq "set" and "add" methods yield different results.

[Claude Warren (Jira)]

Claude Warren created JENA-2075:
---

 Summary: Seq "set" and "add" methods yield different results.
 Key: JENA-2075
 URL: https://issues.apache.org/jira/browse/JENA-2075
 Project: Apache Jena
  Issue Type: Bug
  Components: Core
Affects Versions: Jena 3.17.0
Reporter: Claude Warren


I think the issue is in the Seq.set() method but the if the example below is 
executed the results are variously boolean values or strings representing 
boolean values.

Code:
{code:java}
import org.apache.jena.rdf.model.Model;
import org.apache.jena.rdf.model.ModelFactory;
import org.apache.jena.rdf.model.Seq;

public class SeqTest {
public static void main(String[] args) {
Model m = ModelFactory.createDefaultModel();
Seq seq = m.createSeq();
seq.add( 1L );
seq.add(2, 2L );
m.write(System.out, "TURTLE");
seq.set(1, 1L);
m.write(System.out, "TURTLE");
}
}

{code}
Result:
{code:java}
[ a    ;
  
  "1" ;
  
  "2"
] .
[ a    ;
  
  "1"^^ ;
  
  "2"
] .
{code}
The Collection.add() code and the Seq.add() methods both insert string 
representations for the long values.  The Seq.set() method on the other hand 
places a typed literal in the graph. 

Personally I would rather see the typed literal but I don't know that the 
standard says.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (JENA-2055) handle properly the denied access generated by jena-permission security evaluator

[Claude Warren (Jira)]

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

Claude Warren commented on JENA-2055:
-

I have two items to bring up here:

*One – The record code for OperationDeniedException*

I think there is a problem with the original solution.  If the problem is that 
authentication is required the system returns a 403 (forbidden) rather than a 
401 (unauthorized).  The issue in in the patch at the line that reads:
{code:java}
if ( ex.getCause() != null && ex.getCause() instanceof OperationDeniedException 
){code}
The code that follows should distinguish between the AccessDenied and the 
AuthenticationRequired exceptions.  I think that CannotCreate should proibably 
go with AccessDenied.

*Two – The permissions issue in UNION*

The work around for this problem  is to modify the SecurityEvaluator.

Background:

The system verifies that the user has access to the graph, if not it throws the 
ReadDeniedException.  However, if the user has access to the graph then the 
system will look at each triple and verify access.  So if the SecurityEvaluator 
returns true for graph access and then false for every triple the system will 
work.

 

The solution is probably to change the find() methods so that hey call 
canRead() rather than checkRead() and if canRead() returns false then return an 
empty iterator..

 

 

> handle properly the denied access generated by jena-permission security 
> evaluator
> -
>
> Key: JENA-2055
> URL: https://issues.apache.org/jira/browse/JENA-2055
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Affects Versions: Jena 3.17.0
> Environment: jena-fuseki 3.17.0
> openjdk version "1.8.0_275"
>Reporter: info parlepeuple
>Assignee: Andy Seaborne
>Priority: Major
>  Labels: fuseki2, permission
> Fix For: Jena 4.0.0
>
> Attachments: 
> 0001-handle-properly-the-denied-access-generated-by-jena.patch, 
> ShiroEvaluator.java, localData.ttl, pom.xml
>
>
> When the dataset is secured with [jena 
> permission|https://jena.apache.org/documentation/permissions/] , and some 
> access is denied, an exception is thrown from the SecuredGraph.
> This exception is not catched in SPARQLQueryProcessor, which results in a 500 
> error returned to the HTTP client.
> exception OperationDeniedException should return a 403, not a 500.
>  
> attached is the patch !
>  
> [2021-02-21 03:10:26] Fuseki WARN [3] RC = 500 : Model permissions violation:
>  org.apache.jena.shared.ReadDeniedException: Model permissions violation:
>  at 
> org.apache.jena.permissions.impl.SecuredItemImpl.checkRead(SecuredItemImpl.java:683)
>  ~[jena-permissions-3.17.0.jar:3.17.0]
>  at 
> org.apache.jena.permissions.graph.impl.SecuredGraphImpl.find(SecuredGraphImpl.java:154)
>  ~[jena-permissions-3.17.0.jar:3.17.0]
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_275]
>  at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> ~[?:1.8.0_275]
>  at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  ~[?:1.8.0_275]
>  at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_275]
>  at 
> org.apache.jena.permissions.impl.SecuredItemInvoker.invoke(SecuredItemInvoker.java:120)
>  ~[jena-permissions-3.17.0.jar:3.17.0]
>  at com.sun.proxy.$Proxy18.find(Unknown Source) ~[?:?]
>  at 
> org.apache.jena.sparql.graph.GraphUnionRead.graphBaseFind(GraphUnionRead.java:104)
>  ~[fuseki-server.jar:3.17.0]
>  at org.apache.jena.graph.impl.GraphBase.find(GraphBase.java:244) 
> ~[fuseki-server.jar:3.17.0]
>  at org.apache.jena.graph.impl.GraphBase.graphBaseFind(GraphBase.java:261) 
> ~[fuseki-server.jar:3.17.0]
>  at org.apache.jena.graph.impl.GraphBase.find(GraphBase.java:258) 
> ~[fuseki-server.jar:3.17.0]
>  at org.apache.jena.graph.impl.WrappedGraph.find(WrappedGraph.java:100) 
> ~[fuseki-server.jar:3.17.0]
>  at 
> org.apache.jena.sparql.engine.iterator.QueryIterTriplePattern$TripleMapper.(QueryIterTriplePattern.java:83)
>  ~[fuseki-server.jar:3.17.0]
>  at 
> org.apache.jena.sparql.engine.iterator.QueryIterTriplePattern.nextStage(QueryIterTriplePattern.java:52)
>  ~[fuseki-server.jar:3.17.0]
>  at 
> org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.makeNextStage(QueryIterRepeatApply.java:108)
>  ~[fuseki-server.jar:3.17.0]
>  at 
> org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.hasNextBinding(QueryIterRepeatApply.java:65)
>  ~[fuseki-server.jar:3.17.0]
>  at 
> org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
>  ~[fuseki-server.jar:3.17.0]
>  at 
> 

[jira] [Updated] (JENA-1863) ARQ formats query with wrong padding when rdf:type is present

[Claude Warren (Jira)]

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

Claude Warren updated JENA-1863:

Summary: ARQ formats query with wrong padding when rdf:type is present  
(was: Query builder creates query with wrong padding when rdf:type is present)

> ARQ formats query with wrong padding when rdf:type is present
> -
>
> Key: JENA-1863
> URL: https://issues.apache.org/jira/browse/JENA-1863
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.14.0
>Reporter: David Ruszkai
>Priority: Trivial
>
> *Description*
>  Creating a query with any QueryBuilder (SelectBuilder, AskBuilder etc.) when 
> an RDF.type predicate is present will result in a query that contains the 
> character 'a' followed by 19 spaces instead of a single 'a' (shortcut to the 
> RDF.type predicate) or "<[http://www.w3.org/1999/02/22-rdf-syntax-ns#type]>" 
> (the URI of the RDF.type predicate).
> Example:
> {code:java}
> new SelectBuilder().addWhere(createVariable("subject"), 
> org.apache.jena.vocabulary.RDF.type, createVariable("object")).buildString()
> {code}
> OR
> {code:java}
> new SelectBuilder().addWhere(createVariable("subject"), 
> createURI("http://www.w3.org/1999/02/22-rdf-syntax-ns#type;), 
> createVariable("object")).buildString()
> {code}
> OR
> {code:java}
> new SelectBuilder().addWhere(createVariable("subject"), "a", 
> createVariable("object")).buildString()
> {code}
> will create the following query
> {code:java}
> SELECT  *
> WHERE
>   { ?subject  a ?object}
> {code}
> Probably caused by:
>  
> [https://github.com/apache/jena/commit/6570c25be8c6e958a5647a7d2c1e23466498b332]
> *Summary*
> The formatting of the query is invalid when the rdf:type predicate is present.
> *Steps to reproduce*
> Check the result of
> {code:java}
> new SelectBuilder().addWhere(createVariable("subject"), "a", 
> createVariable("object")).buildString()
> {code}
> *Expected results*
> {code:java}
> SELECT  *
> WHERE
>   { ?subject  a  ?object}
> {code}
> *Actual results*
> {code:java}
> SELECT  *
> WHERE
>   { ?subject  a ?object}
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (JENA-1841) Side Effect of Datatype Use in Query

[Claude Warren (Jira)]

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

Claude Warren commented on JENA-1841:
-

Pull [request 704|https://github.com/apache/jena/pull/704] has fixes to throw 
exception when unregistered object type is used to create a literal.  Please 
pay particular attention to the Conversions.makeLiteral() methods (2 of them).

> Side Effect of Datatype  Use in Query
> --
>
> Key: JENA-1841
> URL: https://issues.apache.org/jira/browse/JENA-1841
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.14.0
>Reporter: Jan Martin Keil
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I faced a bug caused by a side effect of using the datatype 
>  in a query.
> Short story is that you can not use this datatype in model parsing or queries 
> after you once used it in a query.
> I did not completely  break it down to a specific piece of code, but I wrote 
> some testcases that narrow down the issue. Please note that the order of 
> execution of the test methods effect the result. So please first try to 
> execute single test methods before executing the whole test class.
> {code:java}
> import java.io.ByteArrayInputStream;
> import java.util.UUID;
> import org.apache.jena.arq.querybuilder.SelectBuilder;
> import org.apache.jena.query.QueryExecution;
> import org.apache.jena.query.QueryExecutionFactory;
> import org.apache.jena.rdf.model.Model;
> import org.apache.jena.rdf.model.ModelFactory;
> import org.junit.jupiter.api.Test;
> public class UuidParsingintoModelOrQuery {
>   @Test
>   public void uuidParsingIntoSingleModel() throws Exception {
>   UUID uuid1 = 
> UUID.fromString("----");
>   UUID uuid2 = 
> UUID.fromString("----0001");
>   String modelStr = "_:a  \"" + uuid1 + 
> "\"^^ .\n"
>   + "_:a  \"" + uuid1 + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   // repeat
>   modelStr = "_:a  \"" + uuid2 + 
> "\"^^ .\n"
>   + "_:a  \"" + uuid2 + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   }
>   @Test
>   public void sameUuidParsingIntoSingleModel() throws Exception {
>   UUID uuid1 = 
> UUID.fromString("----0002");
>   UUID uuid2 = 
> UUID.fromString("----0003");
>   String modelStr = "_:a  \"" + uuid1 + 
> "\"^^ .\n"
>   + "_:a  \"" + uuid2 + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   // repeat
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   }
>   @Test
>   public void sameUuidParsingIntoMultipleModel() throws Exception {
>   UUID uuid = 
> UUID.fromString("----0004");
>   String modelStr = "_:a  \"" + uuid + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   }
>   @Test
>   public void uuidUseInQuery() throws Exception {
>   UUID uuid = 
> UUID.fromString("----0005");
>   SelectBuilder select = new SelectBuilder();
>   select.addWhere("?a", "", "?uuid");
>   select.addFilter(select.getExprFactory().eq("?uuid", uuid));
>   QueryExecution q = QueryExecutionFactory.create(select.build());
>   }
>   @Test
>   public void uuidParsingIntoQuery() throws Exception {
>   UUID uuid = 
> UUID.fromString("----0006");
>   SelectBuilder select = new SelectBuilder();
>   select.addWhere("?a", "", "?uuid");
>   select.addFilter(select.getExprFactory().eq("?uuid", uuid));
>   QueryExecution q = 
> QueryExecutionFactory.create(select.toString());
>   }
>   @Test
>   public void uuidUseInQueryAndParsingIntoModel() throws Exception {
>   UUID uuid = 
> 

[jira] [Commented] (JENA-1841) Side Effect of Datatype Use in Query

[Claude Warren (Jira)]

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

Claude Warren commented on JENA-1841:
-

I did not intent a full replacement for round-trip object processing.

>From the QueryBuilder perspective we want to generate a "reasonable" value 
>(try to reach the "do not fail").  So if there is no object registered the 
>reasonable thing seems to be to generate a literal like the AdhocDatatype. 

Things that will not work:
 # Round tripping (write object, read object) without registering a Datatype.
 # Objects that do not implement a consistent toString(), but this is the same 
issue that the current LiteralLableImpl has.

The problem is deeper than just QueryBuilder.  I think that all I need to do is 
call new LiteralLabelImpl( object ) and the AdhocDatatype is created and gums 
up the process.  I think we need to fix LiteralLabelImpl.  If the requirement 
is that it can not fail then it needs to generate the URI that it currently 
generates without the AdhocDatatype registration.  Changing it to parse the a 
literal label generated from object.toString() and object.getClass().getName() 
seams reasonable and backwards compatible.  If the parsing fails then we need 
to throw an exception.

 

> Side Effect of Datatype  Use in Query
> --
>
> Key: JENA-1841
> URL: https://issues.apache.org/jira/browse/JENA-1841
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.14.0
>Reporter: Jan Martin Keil
>Priority: Major
>
> I faced a bug caused by a side effect of using the datatype 
>  in a query.
> Short story is that you can not use this datatype in model parsing or queries 
> after you once used it in a query.
> I did not completely  break it down to a specific piece of code, but I wrote 
> some testcases that narrow down the issue. Please note that the order of 
> execution of the test methods effect the result. So please first try to 
> execute single test methods before executing the whole test class.
> {code:java}
> import java.io.ByteArrayInputStream;
> import java.util.UUID;
> import org.apache.jena.arq.querybuilder.SelectBuilder;
> import org.apache.jena.query.QueryExecution;
> import org.apache.jena.query.QueryExecutionFactory;
> import org.apache.jena.rdf.model.Model;
> import org.apache.jena.rdf.model.ModelFactory;
> import org.junit.jupiter.api.Test;
> public class UuidParsingintoModelOrQuery {
>   @Test
>   public void uuidParsingIntoSingleModel() throws Exception {
>   UUID uuid1 = 
> UUID.fromString("----");
>   UUID uuid2 = 
> UUID.fromString("----0001");
>   String modelStr = "_:a  \"" + uuid1 + 
> "\"^^ .\n"
>   + "_:a  \"" + uuid1 + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   // repeat
>   modelStr = "_:a  \"" + uuid2 + 
> "\"^^ .\n"
>   + "_:a  \"" + uuid2 + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   }
>   @Test
>   public void sameUuidParsingIntoSingleModel() throws Exception {
>   UUID uuid1 = 
> UUID.fromString("----0002");
>   UUID uuid2 = 
> UUID.fromString("----0003");
>   String modelStr = "_:a  \"" + uuid1 + 
> "\"^^ .\n"
>   + "_:a  \"" + uuid2 + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   // repeat
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   }
>   @Test
>   public void sameUuidParsingIntoMultipleModel() throws Exception {
>   UUID uuid = 
> UUID.fromString("----0004");
>   String modelStr = "_:a  \"" + uuid + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   }
>   @Test
>   public void uuidUseInQuery() throws Exception {
>   UUID uuid = 
> UUID.fromString("----0005");
>   SelectBuilder select = new SelectBuilder();
>

[jira] [Commented] (JENA-1841) Side Effect of Datatype Use in Query

[Claude Warren (Jira)]

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

Claude Warren commented on JENA-1841:
-

Actually, I wrote that this AM without looking at my test code (DOH!)

What my test code does is construct the literal string and then passes that to 
the {{NodeFactoryExtra.parseNode( string, prefixmap )}} method. But I suspect 
with some digging we could get a method to do what we want.

> Side Effect of Datatype  Use in Query
> --
>
> Key: JENA-1841
> URL: https://issues.apache.org/jira/browse/JENA-1841
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.14.0
>Reporter: Jan Martin Keil
>Priority: Major
>
> I faced a bug caused by a side effect of using the datatype 
>  in a query.
> Short story is that you can not use this datatype in model parsing or queries 
> after you once used it in a query.
> I did not completely  break it down to a specific piece of code, but I wrote 
> some testcases that narrow down the issue. Please note that the order of 
> execution of the test methods effect the result. So please first try to 
> execute single test methods before executing the whole test class.
> {code:java}
> import java.io.ByteArrayInputStream;
> import java.util.UUID;
> import org.apache.jena.arq.querybuilder.SelectBuilder;
> import org.apache.jena.query.QueryExecution;
> import org.apache.jena.query.QueryExecutionFactory;
> import org.apache.jena.rdf.model.Model;
> import org.apache.jena.rdf.model.ModelFactory;
> import org.junit.jupiter.api.Test;
> public class UuidParsingintoModelOrQuery {
>   @Test
>   public void uuidParsingIntoSingleModel() throws Exception {
>   UUID uuid1 = 
> UUID.fromString("----");
>   UUID uuid2 = 
> UUID.fromString("----0001");
>   String modelStr = "_:a  \"" + uuid1 + 
> "\"^^ .\n"
>   + "_:a  \"" + uuid1 + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   // repeat
>   modelStr = "_:a  \"" + uuid2 + 
> "\"^^ .\n"
>   + "_:a  \"" + uuid2 + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   }
>   @Test
>   public void sameUuidParsingIntoSingleModel() throws Exception {
>   UUID uuid1 = 
> UUID.fromString("----0002");
>   UUID uuid2 = 
> UUID.fromString("----0003");
>   String modelStr = "_:a  \"" + uuid1 + 
> "\"^^ .\n"
>   + "_:a  \"" + uuid2 + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   // repeat
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   }
>   @Test
>   public void sameUuidParsingIntoMultipleModel() throws Exception {
>   UUID uuid = 
> UUID.fromString("----0004");
>   String modelStr = "_:a  \"" + uuid + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   }
>   @Test
>   public void uuidUseInQuery() throws Exception {
>   UUID uuid = 
> UUID.fromString("----0005");
>   SelectBuilder select = new SelectBuilder();
>   select.addWhere("?a", "", "?uuid");
>   select.addFilter(select.getExprFactory().eq("?uuid", uuid));
>   QueryExecution q = QueryExecutionFactory.create(select.build());
>   }
>   @Test
>   public void uuidParsingIntoQuery() throws Exception {
>   UUID uuid = 
> UUID.fromString("----0006");
>   SelectBuilder select = new SelectBuilder();
>   select.addWhere("?a", "", "?uuid");
>   select.addFilter(select.getExprFactory().eq("?uuid", uuid));
>   QueryExecution q = 
> QueryExecutionFactory.create(select.toString());
>   }
>   @Test
>   public void uuidUseInQueryAndParsingIntoModel() throws Exception {
>   UUID uuid = 
> 

[jira] [Commented] (JENA-1841) Side Effect of Datatype Use in Query

[Claude Warren (Jira)]

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

Claude Warren commented on JENA-1841:
-

Upon further reflection it seems to me that the automatic registration of an 
AdhocDatatype is incorrect and that the system should never create one as a 
side effect.  I think that the {{LiteralLabelFactory.createTypedLiteral(o)}} 
could return a literal label with the current values without constructing the 
AdhocDatatype.  This would meed the "never fail" requirement, yield results 
that are consistent with historical generation, and avoid the issues where the 
AdhocDatatype is thowing an exception on deserialization of the object.

This could  be done by simpley changing:

{code:java}
LiteralLabelImpl( Object value ) {
RDFDatatype dt = TypeMapper.getInstance().getTypeByValue( value 
);
if (dt == null) {
setWithNewDatatypeForValueClass(value);
} else {
setLiteralLabel_2( value, "", dt );
}
}
{code}

to 

{code:java}
LiteralLabelImpl( Object value ) {
RDFDatatype dt = TypeMapper.getInstance().getTypeByValue( value 
);
if (dt == null) {
setLiteralLabel_3( String.format( "\"%s\"^^", 
o, o.getClass().getName() ), "", true );
} else {
setLiteralLabel_2( value, "", dt );
}
}
{code}
 

 

> Side Effect of Datatype  Use in Query
> --
>
> Key: JENA-1841
> URL: https://issues.apache.org/jira/browse/JENA-1841
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.14.0
>Reporter: Jan Martin Keil
>Priority: Major
>
> I faced a bug caused by a side effect of using the datatype 
>  in a query.
> Short story is that you can not use this datatype in model parsing or queries 
> after you once used it in a query.
> I did not completely  break it down to a specific piece of code, but I wrote 
> some testcases that narrow down the issue. Please note that the order of 
> execution of the test methods effect the result. So please first try to 
> execute single test methods before executing the whole test class.
> {code:java}
> import java.io.ByteArrayInputStream;
> import java.util.UUID;
> import org.apache.jena.arq.querybuilder.SelectBuilder;
> import org.apache.jena.query.QueryExecution;
> import org.apache.jena.query.QueryExecutionFactory;
> import org.apache.jena.rdf.model.Model;
> import org.apache.jena.rdf.model.ModelFactory;
> import org.junit.jupiter.api.Test;
> public class UuidParsingintoModelOrQuery {
>   @Test
>   public void uuidParsingIntoSingleModel() throws Exception {
>   UUID uuid1 = 
> UUID.fromString("----");
>   UUID uuid2 = 
> UUID.fromString("----0001");
>   String modelStr = "_:a  \"" + uuid1 + 
> "\"^^ .\n"
>   + "_:a  \"" + uuid1 + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   // repeat
>   modelStr = "_:a  \"" + uuid2 + 
> "\"^^ .\n"
>   + "_:a  \"" + uuid2 + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   }
>   @Test
>   public void sameUuidParsingIntoSingleModel() throws Exception {
>   UUID uuid1 = 
> UUID.fromString("----0002");
>   UUID uuid2 = 
> UUID.fromString("----0003");
>   String modelStr = "_:a  \"" + uuid1 + 
> "\"^^ .\n"
>   + "_:a  \"" + uuid2 + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   // repeat
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   }
>   @Test
>   public void sameUuidParsingIntoMultipleModel() throws Exception {
>   UUID uuid = 
> UUID.fromString("----0004");
>   String modelStr = "_:a  \"" + uuid + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", 

[jira] [Commented] (JENA-1841) Side Effect of Datatype Use in Query

[Claude Warren (Jira)]

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

Claude Warren commented on JENA-1841:
-

If instead of just calling 
{{NodeFactory.createLiteral(LiteralLabelFactory.createTypedLiteral(o));}} as 
the last resort the following code is used, it passes all the tests in the 
original code block.  In addition, it builds the literal type that would 
normally be built by {{LiteralLabelFactory.createTypedLiteral(0)}} without the 
side effect of registering an RDFDatatype. 

{code:java}

RDFDatatype dt = TypeMapper.getInstance().getTypeByValue( o );
if (dt == null) {
String str = String.format( "\"%s\"^^", o, 
o.getClass().getName() );
return NodeFactoryExtra.parseNode(str, PrefixMapFactory
.createForInput(pMapping));
} else {
return 
NodeFactory.createLiteral(LiteralLabelFactory.createTypedLiteral(o));
}
{code}

I though this is a good compromise as it allows us to read a model containing 
unregistered data types and create a query that will execute correctly.

However I think a better solution would be to add  {{createLiteral}} methods to 
the {{AbstractQueryBuilder}} along the lines of:

{code:java}
public Node makeLiteral(Object o, String type) {
return makeLiteral( o, type, query.getPrefixMapping() );
}

public static Node makeLiteral(Object o, String type, PrefixMapping 
pMapping) {
String str = String.format( "\"%s\"^^<%s>", o, type );
return NodeFactoryExtra.parseNode(str, 
PrefixMapFactory.createForInput(pMapping));
}
{code}

Two methods as that is in line with the {{makeNode}} methods.

This will allow calls like {{makeLiteral( uuid, "java:java.util.UUID")}} to 
create the literal UUID string from the examples above or {{makeLiteral( uuid, 
"urn:MyCoolUUID")}} if you want to be very non-conformist.

Thoughts?

   

> Side Effect of Datatype  Use in Query
> --
>
> Key: JENA-1841
> URL: https://issues.apache.org/jira/browse/JENA-1841
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.14.0
>Reporter: Jan Martin Keil
>Priority: Major
>
> I faced a bug caused by a side effect of using the datatype 
>  in a query.
> Short story is that you can not use this datatype in model parsing or queries 
> after you once used it in a query.
> I did not completely  break it down to a specific piece of code, but I wrote 
> some testcases that narrow down the issue. Please note that the order of 
> execution of the test methods effect the result. So please first try to 
> execute single test methods before executing the whole test class.
> {code:java}
> import java.io.ByteArrayInputStream;
> import java.util.UUID;
> import org.apache.jena.arq.querybuilder.SelectBuilder;
> import org.apache.jena.query.QueryExecution;
> import org.apache.jena.query.QueryExecutionFactory;
> import org.apache.jena.rdf.model.Model;
> import org.apache.jena.rdf.model.ModelFactory;
> import org.junit.jupiter.api.Test;
> public class UuidParsingintoModelOrQuery {
>   @Test
>   public void uuidParsingIntoSingleModel() throws Exception {
>   UUID uuid1 = 
> UUID.fromString("----");
>   UUID uuid2 = 
> UUID.fromString("----0001");
>   String modelStr = "_:a  \"" + uuid1 + 
> "\"^^ .\n"
>   + "_:a  \"" + uuid1 + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   // repeat
>   modelStr = "_:a  \"" + uuid2 + 
> "\"^^ .\n"
>   + "_:a  \"" + uuid2 + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   }
>   @Test
>   public void sameUuidParsingIntoSingleModel() throws Exception {
>   UUID uuid1 = 
> UUID.fromString("----0002");
>   UUID uuid2 = 
> UUID.fromString("----0003");
>   String modelStr = "_:a  \"" + uuid1 + 
> "\"^^ .\n"
>   + "_:a  \"" + uuid2 + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   // repeat
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   }
>   @Test
>   public void 

[jira] [Commented] (JENA-1841) Side Effect of Datatype Use in Query

[Claude Warren (Jira)]

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

Claude Warren commented on JENA-1841:
-

[~andy] what would happen if we constructed a typed variable without 
registering the AdHocDatatype as is currently done?   Why do we register the 
AdHocDatatype?

> Side Effect of Datatype  Use in Query
> --
>
> Key: JENA-1841
> URL: https://issues.apache.org/jira/browse/JENA-1841
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.14.0
>Reporter: Jan Martin Keil
>Priority: Major
>
> I faced a bug caused by a side effect of using the datatype 
>  in a query.
> Short story is that you can not use this datatype in model parsing or queries 
> after you once used it in a query.
> I did not completely  break it down to a specific piece of code, but I wrote 
> some testcases that narrow down the issue. Please note that the order of 
> execution of the test methods effect the result. So please first try to 
> execute single test methods before executing the whole test class.
> {code:java}
> import java.io.ByteArrayInputStream;
> import java.util.UUID;
> import org.apache.jena.arq.querybuilder.SelectBuilder;
> import org.apache.jena.query.QueryExecution;
> import org.apache.jena.query.QueryExecutionFactory;
> import org.apache.jena.rdf.model.Model;
> import org.apache.jena.rdf.model.ModelFactory;
> import org.junit.jupiter.api.Test;
> public class UuidParsingintoModelOrQuery {
>   @Test
>   public void uuidParsingIntoSingleModel() throws Exception {
>   UUID uuid1 = 
> UUID.fromString("----");
>   UUID uuid2 = 
> UUID.fromString("----0001");
>   String modelStr = "_:a  \"" + uuid1 + 
> "\"^^ .\n"
>   + "_:a  \"" + uuid1 + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   // repeat
>   modelStr = "_:a  \"" + uuid2 + 
> "\"^^ .\n"
>   + "_:a  \"" + uuid2 + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   }
>   @Test
>   public void sameUuidParsingIntoSingleModel() throws Exception {
>   UUID uuid1 = 
> UUID.fromString("----0002");
>   UUID uuid2 = 
> UUID.fromString("----0003");
>   String modelStr = "_:a  \"" + uuid1 + 
> "\"^^ .\n"
>   + "_:a  \"" + uuid2 + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   // repeat
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   }
>   @Test
>   public void sameUuidParsingIntoMultipleModel() throws Exception {
>   UUID uuid = 
> UUID.fromString("----0004");
>   String modelStr = "_:a  \"" + uuid + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   }
>   @Test
>   public void uuidUseInQuery() throws Exception {
>   UUID uuid = 
> UUID.fromString("----0005");
>   SelectBuilder select = new SelectBuilder();
>   select.addWhere("?a", "", "?uuid");
>   select.addFilter(select.getExprFactory().eq("?uuid", uuid));
>   QueryExecution q = QueryExecutionFactory.create(select.build());
>   }
>   @Test
>   public void uuidParsingIntoQuery() throws Exception {
>   UUID uuid = 
> UUID.fromString("----0006");
>   SelectBuilder select = new SelectBuilder();
>   select.addWhere("?a", "", "?uuid");
>   select.addFilter(select.getExprFactory().eq("?uuid", uuid));
>   QueryExecution q = 
> QueryExecutionFactory.create(select.toString());
>   }
>   @Test
>   public void uuidUseInQueryAndParsingIntoModel() throws Exception {
>   UUID uuid = 
> UUID.fromString("----0007");
>   SelectBuilder select = new SelectBuilder();
>

[jira] [Commented] (JENA-1841) Side Effect of Datatype Use in Query

[Claude Warren (Jira)]

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

Claude Warren commented on JENA-1841:
-

Would it make sense that rather than throw an exception just call 
{{createLiteral( o.toString() );}} ? 

I think I understand the issue but I also think that the expected result, from 
a developers perspective, would be for the object to be interpreted as a 
string.  So the result would be

 
// Check the object's java class is a registered.   RDFDatatype dt = 
TypeMapper.getInstance().getTypeByValue( o );  if ( dt == null )
 return NodeFactory.createLiteral( o.toString() );  return 
NodeFactory.createLiteral(LiteralLabelFactory.createTypedLiteral(o));
}
 

Do you see any reason not to do this?

 

> Side Effect of Datatype  Use in Query
> --
>
> Key: JENA-1841
> URL: https://issues.apache.org/jira/browse/JENA-1841
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.14.0
>Reporter: Jan Martin Keil
>Priority: Major
>
> I faced a bug caused by a side effect of using the datatype 
>  in a query.
> Short story is that you can not use this datatype in model parsing or queries 
> after you once used it in a query.
> I did not completely  break it down to a specific piece of code, but I wrote 
> some testcases that narrow down the issue. Please note that the order of 
> execution of the test methods effect the result. So please first try to 
> execute single test methods before executing the whole test class.
> {code:java}
> import java.io.ByteArrayInputStream;
> import java.util.UUID;
> import org.apache.jena.arq.querybuilder.SelectBuilder;
> import org.apache.jena.query.QueryExecution;
> import org.apache.jena.query.QueryExecutionFactory;
> import org.apache.jena.rdf.model.Model;
> import org.apache.jena.rdf.model.ModelFactory;
> import org.junit.jupiter.api.Test;
> public class UuidParsingintoModelOrQuery {
>   @Test
>   public void uuidParsingIntoSingleModel() throws Exception {
>   UUID uuid1 = 
> UUID.fromString("----");
>   UUID uuid2 = 
> UUID.fromString("----0001");
>   String modelStr = "_:a  \"" + uuid1 + 
> "\"^^ .\n"
>   + "_:a  \"" + uuid1 + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   // repeat
>   modelStr = "_:a  \"" + uuid2 + 
> "\"^^ .\n"
>   + "_:a  \"" + uuid2 + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   }
>   @Test
>   public void sameUuidParsingIntoSingleModel() throws Exception {
>   UUID uuid1 = 
> UUID.fromString("----0002");
>   UUID uuid2 = 
> UUID.fromString("----0003");
>   String modelStr = "_:a  \"" + uuid1 + 
> "\"^^ .\n"
>   + "_:a  \"" + uuid2 + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   // repeat
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   }
>   @Test
>   public void sameUuidParsingIntoMultipleModel() throws Exception {
>   UUID uuid = 
> UUID.fromString("----0004");
>   String modelStr = "_:a  \"" + uuid + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   }
>   @Test
>   public void uuidUseInQuery() throws Exception {
>   UUID uuid = 
> UUID.fromString("----0005");
>   SelectBuilder select = new SelectBuilder();
>   select.addWhere("?a", "", "?uuid");
>   select.addFilter(select.getExprFactory().eq("?uuid", uuid));
>   QueryExecution q = QueryExecutionFactory.create(select.build());
>   }
>   @Test
>   public void uuidParsingIntoQuery() throws Exception {
>   UUID uuid = 
> UUID.fromString("----0006");
>   SelectBuilder select = new SelectBuilder();
>   

[jira] [Comment Edited] (JENA-1841) Side Effect of Datatype Use in Query

[Claude Warren (Jira)]

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

Claude Warren edited comment on JENA-1841 at 3/2/20 10:38 PM:
--

When creating a Node from an Object the QueryBuilder code does the following:

convert _null_ to {{Node.ANY}}

if object instance of {{FrontsNode}} check if var and return {{Var.alloc( node 
)}} or node if not var.

if object instance of {{Node}} check if var and return {{Var.alloc( node )}} or 
node if not var.

if object instance of String call {{NodeFactoryExtra.parseNode( string, 
prefixmap )}}  then check for var as above.  If this throws a RiotException 
ignore it and attempt the next conversion

all other cases, call {{NodeFactory.createLiteral( 
LiteralLabelFactory.createTypedLiteral( object ) )}}.

So in the case of a UUID object it will call 
{{LiteralLabelFactory.createTypedLiteral( uuid )}} which will eventually call 
{{TypeMapper.getTypeByValue( uuid )}}.  If that returns null it will "invent a 
datatype", otherwise it will use the RDFDatatype.

In the ExprFactory {{eq( object, object )}} does the following conversions:

if object is null return {{Expr.NONE}}

if object is instance of {{Expr}} return {{(Expr)object}}

otherwise convert to {{Node}} using above process.  If node is Var return 
{{ExprVar( Var )}} otherwise call {{NodeValue.makeNode( node )}}.

Given the {{eq( "?uuid", uuid )}} the toNodeValue will be passed the literal 
node as created by {{LiteralLabelFactory.createTypedLiteral( uuid )}}

So if {{NodeValue.nodeToValue( NodeFactory.createLiteral( 
LiteralLabelFactory.createTypedLiteral( uuid ) ) )}} returns what you are 
expecting the query builder will work.

Andy's solution of registering a new type should work as expected.



was (Author: claudenw):
When creating a Node from an Object the QueryBuilder code does the following:

convert _null_ to {{Node.ANY}}

if object instance of {{FrontsNode}} check if var and return {{Var.alloc( node 
)}} or node if not var.

if object instance of {{Node}} check if var and return {{Var.alloc( node )}} or 
node if not var.

if object instance of String call {{NodeFactoryExtra.parseNode( string, 
prefixmap )}}  then check for var as above.  If this throws a RiotException 
ignore it and attempt the next conversion

all other cases, call {{NodeFactory.createLiteral( 
LiteralLabelFactory.createTypedLiteral( object ) )}}.

So in the case of a UUID object it will call 
{{LiteralLabelFactory.createTypedLiteral( uuid )}} which will eventually call 
{{TypeMapper.getTypeByValue( uuid )}}.  If that returns null it will "invent a 
datatype", otherwise it will use the RDFDatatype.

In the ExprFactory {{eq( object, object )}} does the following conversions:

if object is null return {{Expr.NONE}}

if object is instance of {{Expr}} return {{(Expr)object}}

otherwise convert to {{Node}} using above process.  If node is Var return 
{{ExprVar( Var )}} otherwise call {{NodeValue.makeNode( node )}}.

Given the {{eq( "?uuid", uuid )}} the toNodeValue will be passed the literal 
node as created by {{LiteralLabelFactory.createTypedLiteral( uuid )}}

So if {{NodeValue.nodeToValue( NodeFactory.createLiteral( 
LiteralLabelFactory.createTypedLiteral( uuid ) ) )}} returns what you are 
expecting the query builder will work.

Andy's solution of registering a new type should work as expected.


> Side Effect of Datatype  Use in Query
> --
>
> Key: JENA-1841
> URL: https://issues.apache.org/jira/browse/JENA-1841
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.14.0
>Reporter: Jan Martin Keil
>Priority: Major
>
> I faced a bug caused by a side effect of using the datatype 
>  in a query.
> Short story is that you can not use this datatype in model parsing or queries 
> after you once used it in a query.
> I did not completely  break it down to a specific peace of code, but I wrote 
> some testcases that narrow down the issue. Please note that the order of 
> execution of the test methods effect the result. So please first try to 
> execute single test methods before executing the whole test class.
> {code:java}
> import java.io.ByteArrayInputStream;
> import java.util.UUID;
> import org.apache.jena.arq.querybuilder.SelectBuilder;
> import org.apache.jena.query.QueryExecution;
> import org.apache.jena.query.QueryExecutionFactory;
> import org.apache.jena.rdf.model.Model;
> import org.apache.jena.rdf.model.ModelFactory;
> import org.junit.jupiter.api.Test;
> public class UuidParsingintoModelOrQuery {
>   @Test
>   public void uuidParsingIntoSingleModel() throws Exception {
>   UUID uuid1 = 
> UUID.fromString("----");
>   UUID uuid2 = 
> 

[jira] [Commented] (JENA-1841) Side Effect of Datatype Use in Query

[Claude Warren (Jira)]

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

Claude Warren commented on JENA-1841:
-

When creating a Node from an Object the QueryBuilder code does the following:

convert _null_ to `Node.ANY`

if object instance of `FrontsNode` check if var and return `Var.alloc( node )` 
or node if not var.

if object instance of `Node` check if var and return `Var.alloc( node )` or 
node if not var.

if object instance of String call `NodeFactoryExtra.parseNode( string, 
prefixmap )`  then check for var as above.  If this throws a RiotException 
ignore it and attempt the next conversion

all other cases, call `NodeFactory.createLiteral( 
LiteralLabelFactory.createTypedLiteral( object ) )`.

So in the case of a UUID object it will call 
`LiteralLabelFactory.createTypedLiteral( uuid )` which will eventually call 
`TypeMapper.getTypeByValue( uuid )`.  If that returns null it will "invent a 
datatype", otherwise it will use the RDFDatatype.

In the ExprFactory `eq( object, object )` does the following conversions:

if object is null return `Expr.NONE`

if object is instance of `Expr` return `(Expr)object`

otherwise convert to `Node` using above process.  If node is Var return 
`ExprVar( Var )` otherwise call `NodeValue.makeNode( node )`.

Given the `eq( "?uuid", uuid )` the toNodeValue will be passed the literal node 
as created by `LiteralLabelFactory.createTypedLiteral( uuid )`

So if `NodeValue.nodeToValue( NodeFactory.createLiteral( 
LiteralLabelFactory.createTypedLiteral( uuid ) ) )` returns what you are 
expecting the query builder will work.

Andy's solution of registering a new type should work as expected.

 

> Side Effect of Datatype  Use in Query
> --
>
> Key: JENA-1841
> URL: https://issues.apache.org/jira/browse/JENA-1841
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.14.0
>Reporter: Jan Martin Keil
>Priority: Major
>
> I faced a bug caused by a side effect of using the datatype 
>  in a query.
> Short story is that you can not use this datatype in model parsing or queries 
> after you once used it in a query.
> I did not completely  break it down to a specific peace of code, but I wrote 
> some testcases that narrow down the issue. Please note that the order of 
> execution of the test methods effect the result. So please first try to 
> execute single test methods before executing the whole test class.
> {code:java}
> import java.io.ByteArrayInputStream;
> import java.util.UUID;
> import org.apache.jena.arq.querybuilder.SelectBuilder;
> import org.apache.jena.query.QueryExecution;
> import org.apache.jena.query.QueryExecutionFactory;
> import org.apache.jena.rdf.model.Model;
> import org.apache.jena.rdf.model.ModelFactory;
> import org.junit.jupiter.api.Test;
> public class UuidParsingintoModelOrQuery {
>   @Test
>   public void uuidParsingIntoSingleModel() throws Exception {
>   UUID uuid1 = 
> UUID.fromString("----");
>   UUID uuid2 = 
> UUID.fromString("----0001");
>   String modelStr = "_:a  \"" + uuid1 + 
> "\"^^ .\n"
>   + "_:a  \"" + uuid1 + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   // repeat
>   modelStr = "_:a  \"" + uuid2 + 
> "\"^^ .\n"
>   + "_:a  \"" + uuid2 + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   }
>   @Test
>   public void sameUuidParsingIntoSingleModel() throws Exception {
>   UUID uuid1 = 
> UUID.fromString("----0002");
>   UUID uuid2 = 
> UUID.fromString("----0003");
>   String modelStr = "_:a  \"" + uuid1 + 
> "\"^^ .\n"
>   + "_:a  \"" + uuid2 + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   // repeat
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   }
>   @Test
>   public void sameUuidParsingIntoMultipleModel() throws Exception {
>   UUID uuid = 
> UUID.fromString("----0004");
>   String modelStr = "_:a  \"" + uuid + 
> "\"^^ .";
>   

[jira] [Commented] (JENA-1806) Move all code examples to jena-examples package

[Claude Warren (Jira)]

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

Claude Warren commented on JENA-1806:
-

I think that the package naming should be

 

org.apache.jena.example.\{module}.[module specific package names]

for example

o.a.j.example.querybuilder

o.a.j.example.rdfconnection

o.a.j.example.riot.system

 

 

> Move all code examples to jena-examples package
> ---
>
> Key: JENA-1806
> URL: https://issues.apache.org/jira/browse/JENA-1806
> Project: Apache Jena
>  Issue Type: Improvement
>Affects Versions: Jena 3.13.1
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Currently there are RDFConnection examples in the main code base.  These 
> should be moved to the jena-examples package.
> Code base should be combed for other examples that should be moved as well.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (JENA-1806) Move all code examples to jena-examples package

[Claude Warren (Jira)]

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

Claude Warren edited comment on JENA-1806 at 12/22/19 12:53 PM:


In addition to the RDFConnection examples the following should also be moved:

 
 * 
[jena-arq/src-examples/arq/examples/aggregates/CustomAggregate.java|https://github.com/apache/jena/pull/662/files#diff-0]
 * 
[jena-core/src-examples/jena/examples/ontology/classHierarchy/ClassHierarchy.java|https://github.com/apache/jena/pull/662/files#diff-2]
 * 
[jena-sdb/src-examples/sdb/examples/Ex1.java|https://github.com/apache/jena/pull/662/files#diff-3]
 * 
[jena-sdb/src-examples/sdb/examples/Ex2.java|https://github.com/apache/jena/pull/662/files#diff-4]
 * 
[jena-sdb/src-examples/sdb/examples/ExJdbcConnection.java|https://github.com/apache/jena/pull/662/files#diff-5]
 * 
[jena-tdb/src-examples/tdb/examples/ExQuadFilter.java|https://github.com/apache/jena/pull/662/files#diff-6]
 * 
[jena-tdb/src-examples/tdb/examples/ExTDB4.java|https://github.com/apache/jena/pull/662/files#diff-7]
 * 
[jena-tdb/src-examples/tdb/examples/ExTDB5.java|https://github.com/apache/jena/pull/662/files#diff-8]
 * 
[jena-tdb/src-examples/tdb/examples/ExTDB6.java|https://github.com/apache/jena/pull/662/files#diff-9]
 * 
[jena-tdb/src-examples/tdb/examples/ExTDB_Txn1.java|https://github.com/apache/jena/pull/662/files#diff-10]
 * 
[jena-tdb/src-examples/tdb/examples/ExTDB_Txn2.java|https://github.com/apache/jena/pull/662/files#diff-11]
 * 
[jena-tdb/src-examples/tdb/examples/ExTDB_Txn3.java|https://github.com/apache/jena/pull/662/files#diff-12]

 


was (Author: claudenw):
In addition to the RDFConnection examples the following should also be moved:

 
 * 
[jena-arq/src-examples/arq/examples/aggregates/CustomAggregate.java|https://github.com/apache/jena/pull/662/files#diff-0]
 * 
[jena-arq/src/main/java/org/apache/jena/system/Txn.java|https://github.com/apache/jena/pull/662/files#diff-1]
 * 
[jena-core/src-examples/jena/examples/ontology/classHierarchy/ClassHierarchy.java|https://github.com/apache/jena/pull/662/files#diff-2]
 
 * 
[jena-sdb/src-examples/sdb/examples/Ex1.java|https://github.com/apache/jena/pull/662/files#diff-3]
 
 * 
[jena-sdb/src-examples/sdb/examples/Ex2.java|https://github.com/apache/jena/pull/662/files#diff-4]
 
 * 
[jena-sdb/src-examples/sdb/examples/ExJdbcConnection.java|https://github.com/apache/jena/pull/662/files#diff-5]
 
 * 
[jena-tdb/src-examples/tdb/examples/ExQuadFilter.java|https://github.com/apache/jena/pull/662/files#diff-6]
 
 * 
[jena-tdb/src-examples/tdb/examples/ExTDB4.java|https://github.com/apache/jena/pull/662/files#diff-7]
 
 * 
[jena-tdb/src-examples/tdb/examples/ExTDB5.java|https://github.com/apache/jena/pull/662/files#diff-8]
 
 * 
[jena-tdb/src-examples/tdb/examples/ExTDB6.java|https://github.com/apache/jena/pull/662/files#diff-9]
 
 * 
[jena-tdb/src-examples/tdb/examples/ExTDB_Txn1.java|https://github.com/apache/jena/pull/662/files#diff-10]
 
 * 
[jena-tdb/src-examples/tdb/examples/ExTDB_Txn2.java|https://github.com/apache/jena/pull/662/files#diff-11]
 * 
[jena-tdb/src-examples/tdb/examples/ExTDB_Txn3.java|https://github.com/apache/jena/pull/662/files#diff-12]
 

 

> Move all code examples to jena-examples package
> ---
>
> Key: JENA-1806
> URL: https://issues.apache.org/jira/browse/JENA-1806
> Project: Apache Jena
>  Issue Type: Improvement
>Affects Versions: Jena 3.13.1
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Currently there are RDFConnection examples in the main code base.  These 
> should be moved to the jena-examples package.
> Code base should be combed for other examples that should be moved as well.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (JENA-1806) Move all code examples to jena-examples package

[Claude Warren (Jira)]

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

Claude Warren commented on JENA-1806:
-

In addition to the RDFConnection examples the following should also be moved:

 
 * 
[jena-arq/src-examples/arq/examples/aggregates/CustomAggregate.java|https://github.com/apache/jena/pull/662/files#diff-0]
 * 
[jena-arq/src/main/java/org/apache/jena/system/Txn.java|https://github.com/apache/jena/pull/662/files#diff-1]
 * 
[jena-core/src-examples/jena/examples/ontology/classHierarchy/ClassHierarchy.java|https://github.com/apache/jena/pull/662/files#diff-2]
 
 * 
[jena-sdb/src-examples/sdb/examples/Ex1.java|https://github.com/apache/jena/pull/662/files#diff-3]
 
 * 
[jena-sdb/src-examples/sdb/examples/Ex2.java|https://github.com/apache/jena/pull/662/files#diff-4]
 
 * 
[jena-sdb/src-examples/sdb/examples/ExJdbcConnection.java|https://github.com/apache/jena/pull/662/files#diff-5]
 
 * 
[jena-tdb/src-examples/tdb/examples/ExQuadFilter.java|https://github.com/apache/jena/pull/662/files#diff-6]
 
 * 
[jena-tdb/src-examples/tdb/examples/ExTDB4.java|https://github.com/apache/jena/pull/662/files#diff-7]
 
 * 
[jena-tdb/src-examples/tdb/examples/ExTDB5.java|https://github.com/apache/jena/pull/662/files#diff-8]
 
 * 
[jena-tdb/src-examples/tdb/examples/ExTDB6.java|https://github.com/apache/jena/pull/662/files#diff-9]
 
 * 
[jena-tdb/src-examples/tdb/examples/ExTDB_Txn1.java|https://github.com/apache/jena/pull/662/files#diff-10]
 
 * 
[jena-tdb/src-examples/tdb/examples/ExTDB_Txn2.java|https://github.com/apache/jena/pull/662/files#diff-11]
 * 
[jena-tdb/src-examples/tdb/examples/ExTDB_Txn3.java|https://github.com/apache/jena/pull/662/files#diff-12]
 

 

> Move all code examples to jena-examples package
> ---
>
> Key: JENA-1806
> URL: https://issues.apache.org/jira/browse/JENA-1806
> Project: Apache Jena
>  Issue Type: Improvement
>Affects Versions: Jena 3.13.1
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Currently there are RDFConnection examples in the main code base.  These 
> should be moved to the jena-examples package.
> Code base should be combed for other examples that should be moved as well.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (JENA-1806) Move all code examples to jena-examples package

[Claude Warren (Jira)]

Claude Warren created JENA-1806:
---

 Summary: Move all code examples to jena-examples package
 Key: JENA-1806
 URL: https://issues.apache.org/jira/browse/JENA-1806
 Project: Apache Jena
  Issue Type: Improvement
Affects Versions: Jena 3.13.1
Reporter: Claude Warren
Assignee: Claude Warren


Currently there are RDFConnection examples in the main code base.  These should 
be moved to the jena-examples package.

Code base should be combed for other examples that should be moved as well.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (JENA-1805) Add example of StreamRDF to RDFConnection.

[Claude Warren (Jira)]

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

Claude Warren resolved JENA-1805.
-
Resolution: Fixed

> Add example of StreamRDF to RDFConnection.
> --
>
> Key: JENA-1805
> URL: https://issues.apache.org/jira/browse/JENA-1805
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
>
> As discussed on the mailing list back in July this is an addition to the 
> examples code to show how to implement an StreamRDF that will write to an 
> RDFConnection.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (JENA-1805) Add example of StreamRDF to RDFConnection.

[Claude Warren (Jira)]

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

Claude Warren commented on JENA-1805:
-

Added as part of https://github.com/apache/jena/pull/659

> Add example of StreamRDF to RDFConnection.
> --
>
> Key: JENA-1805
> URL: https://issues.apache.org/jira/browse/JENA-1805
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
>
> As discussed on the mailing list back in July this is an addition to the 
> examples code to show how to implement an StreamRDF that will write to an 
> RDFConnection.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (JENA-1805) Add example of StreamRDF to RDFConnection.

[Claude Warren (Jira)]

Claude Warren created JENA-1805:
---

 Summary: Add example of StreamRDF to RDFConnection.
 Key: JENA-1805
 URL: https://issues.apache.org/jira/browse/JENA-1805
 Project: Apache Jena
  Issue Type: Improvement
Reporter: Claude Warren
Assignee: Claude Warren


As discussed on the mailing list back in July this is an addition to the 
examples code to show how to implement an StreamRDF that will write to an 
RDFConnection.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (JENA-1803) Query builder has no method to merge a where clause

[Claude Warren (Jira)]

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

Claude Warren resolved JENA-1803.
-
Fix Version/s: Jena 3.14.0
   Resolution: Fixed

> Query builder has no method to merge a where clause
> ---
>
> Key: JENA-1803
> URL: https://issues.apache.org/jira/browse/JENA-1803
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: QueryBuilder
>Affects Versions: Jena 3.13.1
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
> Fix For: Jena 3.14.0
>
>
> The AbstractQueryBuilder does not have a mechanism to add entire where clause 
> to the query.
> this would be a addWhere() method that takes a WhereBuilder as an argument, 
> takes the entire where clause of  the argument as an element and adds it to 
> the elements in the queryBuilder.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (JENA-1803) Query builder has no method to merge a where clause

[Claude Warren (Jira)]

Claude Warren created JENA-1803:
---

 Summary: Query builder has no method to merge a where clause
 Key: JENA-1803
 URL: https://issues.apache.org/jira/browse/JENA-1803
 Project: Apache Jena
  Issue Type: Improvement
  Components: QueryBuilder
Affects Versions: Jena 3.13.1
Reporter: Claude Warren
Assignee: Claude Warren


The AbstractQueryBuilder does not have a mechanism to add entire where clause 
to the query.

this would be a addWhere() method that takes a WhereBuilder as an argument, 
takes the entire where clause of  the argument as an element and adds it to the 
elements in the queryBuilder.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (JENA-909) Create Docker launcher for Fuseki

[Claude Warren (Jira)]

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

Claude Warren commented on JENA-909:


Would it make sense to put the maven docker build stuff into an project in 
Extras (I'm always looking for companionship for QueryBuilder).  I think this 
is useful but not mainline code.  Also, there is a maven plugin that will use 
the standard docker.yml file to build the image.  We could tag the image is 
snapshot and have the release build/deploy the real release version.

I have built Maven poms that work this way at work.  We basically push to a 
snapshot docker respoitory on nightly and production level repository on 
release.

[~stain] [~graphity] do either of you feel like your packaging could work this 
way?

> Create Docker launcher for Fuseki
> -
>
> Key: JENA-909
> URL: https://issues.apache.org/jira/browse/JENA-909
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Fuseki
>Reporter: Andy Seaborne
>Priority: Major
>
> Provide a Docker launcher and setup documentation for  Fuseki2.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (JENA-1704) Enable Apache Sonar reports

[Claude Warren (Jira)]

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

Claude Warren commented on JENA-1704:
-

My reading of 
https://docs.sonarqube.org/latest/architecture/architecture-integration/ is 
that we would have to run SonarScanner as part of the build process for the 
sonar service ( SonarQube Server  and  SonarQube Database) to report it. 

We could do this as part of the site processing and just add site processing to 
the nightly build.  I think this would give us the speed we like for 
development, a nightly or on-demand report of the state of the code base as 
well as SonarQube reports.

I could be wrong about all of the above.

> Enable Apache Sonar reports
> ---
>
> Key: JENA-1704
> URL: https://issues.apache.org/jira/browse/JENA-1704
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Build
>Reporter: Adam Soroka
>Assignee: Adam Soroka
>Priority: Trivial
>
> Apache offers a Sonar service at [https://builds.apache.org/analysis.] We 
> should take advantage of it in a non-intrusive way. Enabling Sonar analysis 
> must not annoy anyone working on the codebase or make development less 
> pleasant, so it must be done carefully.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (JENA-1704) Enable Apache Sonar reports

[Claude Warren (Jira)]

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

Claude Warren commented on JENA-1704:
-

If Sonar were added to the site build then it (along with the other reports) 
could be generated on demand.

I have a pre latest release branch (I will update to latest head soon) that 
builds most of the standard reports across the entire set of packages. 
(https://github.com/Claudenw/jena/tree/mavenise-site)  on my github jena on the 
mavenise-site branch. 

Claude

> Enable Apache Sonar reports
> ---
>
> Key: JENA-1704
> URL: https://issues.apache.org/jira/browse/JENA-1704
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Build
>Reporter: Adam Soroka
>Assignee: Adam Soroka
>Priority: Trivial
>
> Apache offers a Sonar service at [https://builds.apache.org/analysis.] We 
> should take advantage of it in a non-intrusive way. Enabling Sonar analysis 
> must not annoy anyone working on the codebase or make development less 
> pleasant, so it must be done carefully.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (JENA-1765) Ensure that maven site:site and site:stage will build a proper jena site.

[Claude Warren (Jira)]

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

Claude Warren commented on JENA-1765:
-

There were some discussions about better test coverage and bug detection.  The 
site:site and site:stage will generate a number of reports that we can use to 
better the code base.

I was hoping to get site:site to generate the site so that we could put the 
"static" pages in the code base and move out of SVN for that component.  But 
that may be a pipe dream.

I have the system mostly building but have encountered issues with the shaded 
guava files.  Even when I do a preliminary "mvn install"  But I think I have a 
solution.  

> Ensure that maven site:site and site:stage will build a proper jena site.
> -
>
> Key: JENA-1765
> URL: https://issues.apache.org/jira/browse/JENA-1765
> Project: Apache Jena
>  Issue Type: Story
>Affects Versions: Jena 3.13.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
>   Original Estimate: 0.05h
>  Remaining Estimate: 0.05h
>
> This change is achieve 3 things:
> 1) To get the site:site and site:stage to execute correctly.  Correctly is 
> defined as generating a number of standard reports
> javadoc - java documentation
> surefire - test execution
> jacoco - test coverage
> PMD - coding rules
> CPD - duplicate code detection
> spotbuts - bug detection
> checkstyle - style checking (disabled until we can come up with the minimum 
> rules)
> 2) The site:site and site:stage should attempt to generate the public facing 
> site complete with formatting as it exists now.
> 3) The site:site and site:stage should be modified to add the reports for the 
> components to the web site.  This will entail discussion concerning where 
> they should go in the structure.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (JENA-1765) Ensure that maven site:site and site:stage will build a proper jena site.

[Claude Warren (Jira)]

Claude Warren created JENA-1765:
---

 Summary: Ensure that maven site:site and site:stage will build a 
proper jena site.
 Key: JENA-1765
 URL: https://issues.apache.org/jira/browse/JENA-1765
 Project: Apache Jena
  Issue Type: Story
Affects Versions: Jena 3.13.0
Reporter: Claude Warren
Assignee: Claude Warren


This change is achieve 3 things:

1) To get the site:site and site:stage to execute correctly.  Correctly is 
defined as generating a number of standard reports

javadoc - java documentation
surefire - test execution
jacoco - test coverage
PMD - coding rules
CPD - duplicate code detection
spotbuts - bug detection
checkstyle - style checking (disabled until we can come up with the minimum 
rules)

2) The site:site and site:stage should attempt to generate the public facing 
site complete with formatting as it exists now.

3) The site:site and site:stage should be modified to add the reports for the 
components to the web site.  This will entail discussion concerning where they 
should go in the structure.




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (JENA-1755) Improve documentation of Query Builders

[Claude Warren (Jira)]

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

Claude Warren commented on JENA-1755:
-

I became aware of this issue during the discussion of JENA-1751 which I then 
used in my talk at ApacheCon when I was discussing the difficulty in finding 
documentation.  I am very interested in helping to sort out this issue and will 
both author and review documentation.  We may need to revisit how we distribute 
the documentation across the site.  But I think that can wait until we get the 
documentation for Query builder in good shape.

> Improve documentation of Query Builders
> ---
>
> Key: JENA-1755
> URL: https://issues.apache.org/jira/browse/JENA-1755
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Jan Martin Keil
>Priority: Major
>
> As discussed in JENA-1751, I propose to improve the documentation of the 
> query builders:
> {quote}Unfortunately, I did not find (and I think there isn't) any 
> documentation or tutorial about the query builders explaining more than the 
> very basics. Also the JavaDoc (which is to the best of my knowledge nowhere 
> linked on [https://jena.apache.org/]), is, in my experience, not helpful and 
> makes it often necessary to look into the code to understand what is needed 
> and maybe find out how to get it. If I did not miss a comprehensive 
> documentation somewhere, I think it would be worth, to improve documentation. 
> Even a few words at the builder classes (mentioning e.g. ExprFactory) and 
> small examples at the more complicated methods would help a lot.
> {quote}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Commented] (JENA-1751) Enable inline use of Element Subclasses

[Claude Warren (Jira)]

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

Claude Warren commented on JENA-1751:
-

> Unfortunately not. For example, (NOT) EXISTS requires to use Element 
> subclasses.

You can use the ExprFactory from the QueryBuilder pacakge to do EXISTS() and 
NOT().  You can construct an ExprFactory by itself or ask an instance of 
AbstractQueryBuilder to return one.

the ExprFactory.exists() takes a  WhereClause as an argument so any 
QueryBuilder will work as will the WhereBuilder.

If QueryBuilder does not work, I would like to understand why.


> Enable inline use of Element Subclasses
> ---
>
> Key: JENA-1751
> URL: https://issues.apache.org/jira/browse/JENA-1751
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Jan Martin Keil
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> To enable the inline use of 
> {{org.apache.jena.sparql.syntax.ElementTriplesBlock}} during query 
> generation, I propose to:
>  * add constructor {{public ElementTriplesBlock(Triple triple)}}
>  * add constructor {{public ElementTriplesBlock(Node s, Node p, Node o)}}
>  * add {{return this}} to
>  ** {{addTriple(Triple t)}}
>  ** {{addTriple(int index, Triple t)}}
>  ** {{addTriplePath(TriplePath path)}}
>  ** {{addTriplePath(int index, TriplePath path)}}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Resolved] (JENA-1739) Using Path in UpdateBuilder#addWhere throws an Exception

[Claude Warren (JIRA)]

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

Claude Warren resolved JENA-1739.
-
   Resolution: Fixed
Fix Version/s: Jena 3.13.0

fixed both addTriple with path and addOptional with path

> Using Path in UpdateBuilder#addWhere throws an Exception
> 
>
> Key: JENA-1739
> URL: https://issues.apache.org/jira/browse/JENA-1739
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.10.0
>Reporter: Vadim Gubin
>Assignee: Claude Warren
>Priority: Major
> Fix For: Jena 3.13.0
>
>
> java.lang.IllegalArgumentException: Predicate ("[some path here, for example 
> (S|^S)/((S|^S))?]"^^java:org.apache.jena.sparql.path.P_Seq) must be a Path, 
> URI , variable, or a wildcard. 
> Is a prefix missing? Prefix must be defined before use.
>  at 
> org.apache.jena.arq.querybuilder.updatebuilder.WhereQuadHolder.testTriple(WhereQuadHolder.java:190)
>  at 
> org.apache.jena.arq.querybuilder.updatebuilder.WhereQuadHolder.addWhere(WhereQuadHolder.java:204)
>  at 
> org.apache.jena.arq.querybuilder.UpdateBuilder.addWhere(UpdateBuilder.java:813)
>  at 
> org.apache.jena.arq.querybuilder.UpdateBuilder.addWhere(UpdateBuilder.java:983)
>  at 
> org.apache.jena.arq.querybuilder.UpdateBuilder.addWhere(UpdateBuilder.java:1012)
>  
> h4. How to reproduce:
> Path path = createSomePath()...
> UpdateRequest update = new UpdateRequest(new UpdateBuilder()
> .addWhere(subject, path, object)
> .build());
>  
> RDFConnectionRemoteBuilder connectionBuilder = 
> connectionBuilderFactory.createConnectionBuilder();
> try (RDFConnection connection = connectionBuilder.build()) {
>  connection.update(update);
> }
> h4. Workaround:
> .addWhere(new TriplePath(subject, path, object));



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (JENA-1739) Using Path in UpdateBuilder#addWhere throws an Exception

[Claude Warren (JIRA)]

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

Claude Warren commented on JENA-1739:
-

Add delete and add insert methods were not updated for this bug as they appear 
to be correct.

> Using Path in UpdateBuilder#addWhere throws an Exception
> 
>
> Key: JENA-1739
> URL: https://issues.apache.org/jira/browse/JENA-1739
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.10.0
>Reporter: Vadim Gubin
>Assignee: Claude Warren
>Priority: Major
>
> java.lang.IllegalArgumentException: Predicate ("[some path here, for example 
> (S|^S)/((S|^S))?]"^^java:org.apache.jena.sparql.path.P_Seq) must be a Path, 
> URI , variable, or a wildcard. 
> Is a prefix missing? Prefix must be defined before use.
>  at 
> org.apache.jena.arq.querybuilder.updatebuilder.WhereQuadHolder.testTriple(WhereQuadHolder.java:190)
>  at 
> org.apache.jena.arq.querybuilder.updatebuilder.WhereQuadHolder.addWhere(WhereQuadHolder.java:204)
>  at 
> org.apache.jena.arq.querybuilder.UpdateBuilder.addWhere(UpdateBuilder.java:813)
>  at 
> org.apache.jena.arq.querybuilder.UpdateBuilder.addWhere(UpdateBuilder.java:983)
>  at 
> org.apache.jena.arq.querybuilder.UpdateBuilder.addWhere(UpdateBuilder.java:1012)
>  
> h4. How to reproduce:
> Path path = createSomePath()...
> UpdateRequest update = new UpdateRequest(new UpdateBuilder()
> .addWhere(subject, path, object)
> .build());
>  
> RDFConnectionRemoteBuilder connectionBuilder = 
> connectionBuilderFactory.createConnectionBuilder();
> try (RDFConnection connection = connectionBuilder.build()) {
>  connection.update(update);
> }
> h4. Workaround:
> .addWhere(new TriplePath(subject, path, object));



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (JENA-1739) Using Path in UpdateBuilder#addWhere throws an Exception

[Claude Warren (JIRA)]

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

Claude Warren commented on JENA-1739:
-

This is a but isolated to the UpdateBuilder.  Code needs to be added to test 
for predicate being an path object for 3-argument methods addWhere, addOptional 
and addDelete as well as the 4-argument addDelete method.

For completeness 4 methods should be added addDeletePath( Iterator 
), addDeletePath( Collection ) , addInsertPath( 
Iterator ) and addInsertPath( Collection )




> Using Path in UpdateBuilder#addWhere throws an Exception
> 
>
> Key: JENA-1739
> URL: https://issues.apache.org/jira/browse/JENA-1739
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.10.0
>Reporter: Vadim Gubin
>Assignee: Claude Warren
>Priority: Major
>
> java.lang.IllegalArgumentException: Predicate ("[some path here, for example 
> (S|^S)/((S|^S))?]"^^java:org.apache.jena.sparql.path.P_Seq) must be a Path, 
> URI , variable, or a wildcard. 
> Is a prefix missing? Prefix must be defined before use.
>  at 
> org.apache.jena.arq.querybuilder.updatebuilder.WhereQuadHolder.testTriple(WhereQuadHolder.java:190)
>  at 
> org.apache.jena.arq.querybuilder.updatebuilder.WhereQuadHolder.addWhere(WhereQuadHolder.java:204)
>  at 
> org.apache.jena.arq.querybuilder.UpdateBuilder.addWhere(UpdateBuilder.java:813)
>  at 
> org.apache.jena.arq.querybuilder.UpdateBuilder.addWhere(UpdateBuilder.java:983)
>  at 
> org.apache.jena.arq.querybuilder.UpdateBuilder.addWhere(UpdateBuilder.java:1012)
>  
> h4. How to reproduce:
> Path path = createSomePath()...
> UpdateRequest update = new UpdateRequest(new UpdateBuilder()
> .addWhere(subject, path, object)
> .build());
>  
> RDFConnectionRemoteBuilder connectionBuilder = 
> connectionBuilderFactory.createConnectionBuilder();
> try (RDFConnection connection = connectionBuilder.build()) {
>  connection.update(update);
> }
> h4. Workaround:
> .addWhere(new TriplePath(subject, path, object));



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Assigned] (JENA-1739) Using Path in UpdateBuilder#addWhere throws an Exception

[Claude Warren (JIRA)]

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

Claude Warren reassigned JENA-1739:
---

Assignee: Claude Warren

> Using Path in UpdateBuilder#addWhere throws an Exception
> 
>
> Key: JENA-1739
> URL: https://issues.apache.org/jira/browse/JENA-1739
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.10.0
>Reporter: Vadim Gubin
>Assignee: Claude Warren
>Priority: Major
>
> java.lang.IllegalArgumentException: Predicate ("[some path here, for example 
> (S|^S)/((S|^S))?]"^^java:org.apache.jena.sparql.path.P_Seq) must be a Path, 
> URI , variable, or a wildcard. 
> Is a prefix missing? Prefix must be defined before use.
>  at 
> org.apache.jena.arq.querybuilder.updatebuilder.WhereQuadHolder.testTriple(WhereQuadHolder.java:190)
>  at 
> org.apache.jena.arq.querybuilder.updatebuilder.WhereQuadHolder.addWhere(WhereQuadHolder.java:204)
>  at 
> org.apache.jena.arq.querybuilder.UpdateBuilder.addWhere(UpdateBuilder.java:813)
>  at 
> org.apache.jena.arq.querybuilder.UpdateBuilder.addWhere(UpdateBuilder.java:983)
>  at 
> org.apache.jena.arq.querybuilder.UpdateBuilder.addWhere(UpdateBuilder.java:1012)
>  
> h4. How to reproduce:
> Path path = createSomePath()...
> UpdateRequest update = new UpdateRequest(new UpdateBuilder()
> .addWhere(subject, path, object)
> .build());
>  
> RDFConnectionRemoteBuilder connectionBuilder = 
> connectionBuilderFactory.createConnectionBuilder();
> try (RDFConnection connection = connectionBuilder.build()) {
>  connection.update(update);
> }
> h4. Workaround:
> .addWhere(new TriplePath(subject, path, object));



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (JENA-1734) Add FUSEKI_BASE extra classes directory

[Claude Warren (JIRA)]

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

Claude Warren commented on JENA-1734:
-

 [pull request|https://github.com/apache/jena/pull/584]

> Add FUSEKI_BASE extra classes directory
> ---
>
> Key: JENA-1734
> URL: https://issues.apache.org/jira/browse/JENA-1734
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Fuseki
>Affects Versions: Jena 3.12.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Trivial
>
> Currently the fuseki-server script has comments about how to modify the file 
> to add extra classes.  This can be rather problematic when working in a 
> containerized environment like Docker.
> This proposal is to add $FUSEKI_BASE/extra/* to the classpath for 
> fuseki-server so that persistent containers like stain/jena-fuseki have a 
> non-instrusive mechanism to add/update extra or 3rd party classes.
> I don't see how to implement this in the windows batch file as it does not 
> appear to have environment variables set for similar purposes to the linux 
> scripts.
> *Background:*
> When running in docker it is possible to mount the FUSEKI_BASE either to 
> local storage or on a docker volume.  This makes it easier to update the Jena 
> /fusekilibraries without losing the data.  However, any edits made to add 
> jars to FUSEKI_HOME are lost during the update.  Adding the 
> $FUSEKI_BASE/extra to the startup script means that 3rd party libraries are 
> treated like data and not removed when the Jena/fuseki code is updated.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Created] (JENA-1734) Add FUSEKI_BASE extra classes directory

[Claude Warren (JIRA)]

Claude Warren created JENA-1734:
---

 Summary: Add FUSEKI_BASE extra classes directory
 Key: JENA-1734
 URL: https://issues.apache.org/jira/browse/JENA-1734
 Project: Apache Jena
  Issue Type: Improvement
  Components: Fuseki
Affects Versions: Jena 3.12.0
Reporter: Claude Warren
Assignee: Claude Warren


Currently the fuseki-server script has comments about how to modify the file to 
add extra classes.  This can be rather problematic when working in a 
containerized environment like Docker.

This proposal is to add $FUSEKI_BASE/extra/* to the classpath for fuseki-server 
so that persistent containers like stain/jena-fuseki have a non-instrusive 
mechanism to add/update extra or 3rd party classes.

I don't see how to implement this in the windows batch file as it does not 
appear to have environment variables set for similar purposes to the linux 
scripts.

*Background:*

When running in docker it is possible to mount the FUSEKI_BASE either to local 
storage or on a docker volume.  This makes it easier to update the Jena 
/fusekilibraries without losing the data.  However, any edits made to add jars 
to FUSEKI_HOME are lost during the update.  Adding the $FUSEKI_BASE/extra to 
the startup script means that 3rd party libraries are treated like data and not 
removed when the Jena/fuseki code is updated.




--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Resolved] (JENA-1515) Values added to subQuery are stripped by QueryBuilder

[Claude Warren (JIRA)]

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

Claude Warren resolved JENA-1515.
-
   Resolution: Fixed
Fix Version/s: Jena 3.10.0

> Values added to subQuery are stripped by QueryBuilder
> -
>
> Key: JENA-1515
> URL: https://issues.apache.org/jira/browse/JENA-1515
> Project: Apache Jena
>  Issue Type: Bug
>  Components: QueryBuilder
>Affects Versions: Jena 3.6.0, Jena 3.7.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
> Fix For: Jena 3.10.0
>
>
> If values are added to a subQuery via the addValue methods the values are 
> stripped when the subquery is added to the outer query.
>  



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

[jira] [Resolved] (JENA-1602) Update builder has no mechanism to add inserts or deletes based on model or triple collections

[Claude Warren (JIRA)]

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

Claude Warren resolved JENA-1602.
-
   Resolution: Fixed
Fix Version/s: Jena 3.10.0

> Update builder has no mechanism to add inserts or deletes based on model or 
> triple collections
> --
>
> Key: JENA-1602
> URL: https://issues.apache.org/jira/browse/JENA-1602
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: QueryBuilder
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
> Fix For: Jena 3.10.0
>
>
> Currently the query builder allows insert/delete of single triples, this 
> change would be  to accept a model as a collection of triples to 
> insert/delete.  In addition a collection of  could be 
> added/deleted.



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

[jira] [Updated] (JENA-1368) Remove regex based where clause tests

[Claude Warren (JIRA)]

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

Claude Warren updated JENA-1368:

Issue Type: Improvement  (was: Bug)

> Remove regex based where clause tests
> -
>
> Key: JENA-1368
> URL: https://issues.apache.org/jira/browse/JENA-1368
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: QueryBuilder
>Affects Versions: Jena 3.3.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
>
> Many tests currently use a regular expression matching of string output to 
> verify that a where clause was constructed properly.  This  change is to use  
> the new WhereValidator code instead.



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

[jira] [Updated] (JENA-1613) When registering an incompatible Datatype a warning should be logged

[Claude Warren (JIRA)]

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

Claude Warren updated JENA-1613:

Description: 
Classes that extend AdhocDatatype (or Basedatatype) and want to allow multiple 
instances of the datatype class to be considered equal must do the following:
 # Override BaseDatatype.isEqual(LiteralLabel litLabel1, LiteralLabel 
litLabel2) to call isEqualByTerm(LiteralLabel litLabel1, LiteralLabel 
litLabel2).
 # Override Object.equals(Object obj)
 # Override Object.hashCode(), potentially calling BaseDatatype.getHashCode( 
LiteralLabel lit )


There should be a warning in the log if TypeMapper.register(RDFDatatype type ) 
is called and there is an existing datatype registered for the 
type.getJavaClass() 


 

  was:
Classes that extend AdhocDatatype (or Basedatatype) and want to allow multiple 
instances of the datatype class to be considered equal must do the following:
 # Override BaseDatatype.isEqual(LiteralLabel litLabel1, LiteralLabel 
litLabel2) to call isEqualByTerm(LiteralLabel litLabel1, LiteralLabel 
litLabel2).
 # Override Object.equals(Object obj)
 # Override Object.hashCode(), potentially calling BaseDatatype.getHashCode( 
LiteralLabel lit )


There should be a warning in the log if TypeMapper.register(RDFDatatype type ) 
is called and there is an existing datatype registered for the 
type.getJavaClass() ; and


 


> When registering an incompatible Datatype a warning should be logged
> 
>
> Key: JENA-1613
> URL: https://issues.apache.org/jira/browse/JENA-1613
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: Jena 3.8.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
>
> Classes that extend AdhocDatatype (or Basedatatype) and want to allow 
> multiple instances of the datatype class to be considered equal must do the 
> following:
>  # Override BaseDatatype.isEqual(LiteralLabel litLabel1, LiteralLabel 
> litLabel2) to call isEqualByTerm(LiteralLabel litLabel1, LiteralLabel 
> litLabel2).
>  # Override Object.equals(Object obj)
>  # Override Object.hashCode(), potentially calling BaseDatatype.getHashCode( 
> LiteralLabel lit )
> There should be a warning in the log if TypeMapper.register(RDFDatatype type 
> ) is called and there is an existing datatype registered for the 
> type.getJavaClass() 
>  



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

[jira] [Updated] (JENA-1613) When registering an incompatible Datatype a warning should be logged

[Claude Warren (JIRA)]

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

Claude Warren updated JENA-1613:

Description: 
Classes that extend AdhocDatatype (or Basedatatype) and want to allow multiple 
instances of the datatype class to be considered equal must do the following:
 # Override BaseDatatype.isEqual(LiteralLabel litLabel1, LiteralLabel 
litLabel2) to call isEqualByTerm(LiteralLabel litLabel1, LiteralLabel 
litLabel2).
 # Override Object.equals(Object obj)
 # Override Object.hashCode(), potentially calling BaseDatatype.getHashCode( 
LiteralLabel lit )


There should be a warning in the log if TypeMapper.register(RDFDatatype type ) 
is called and there is an existing datatype registered for the 
type.getJavaClass() ; and


 

  was:
Classes that extend AdhocDatatype (or Basedatatype) and want to allow multiple 
instances of the datatype class to be considered equal must do the following:
 # Override BaseDatatype.isEqual(LiteralLabel litLabel1, LiteralLabel 
litLabel2) to call isEqualByTerm(LiteralLabel litLabel1, LiteralLabel 
litLabel2).
 # Override Object.equals(Object obj)
 # Override Object.hashCode(), potentially calling BaseDatatype.getHashCode( 
LiteralLabel lit )


There should be a warning in the log if TypeMapper.register(RDFDatatype type ) 
is called and:
 # There is an existing datatype registered for the type.getJavaClass() ; and
 # There registered type.isEquals( type.registeredType ) is false.

 


> When registering an incompatible Datatype a warning should be logged
> 
>
> Key: JENA-1613
> URL: https://issues.apache.org/jira/browse/JENA-1613
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: Jena 3.8.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
>
> Classes that extend AdhocDatatype (or Basedatatype) and want to allow 
> multiple instances of the datatype class to be considered equal must do the 
> following:
>  # Override BaseDatatype.isEqual(LiteralLabel litLabel1, LiteralLabel 
> litLabel2) to call isEqualByTerm(LiteralLabel litLabel1, LiteralLabel 
> litLabel2).
>  # Override Object.equals(Object obj)
>  # Override Object.hashCode(), potentially calling BaseDatatype.getHashCode( 
> LiteralLabel lit )
> There should be a warning in the log if TypeMapper.register(RDFDatatype type 
> ) is called and there is an existing datatype registered for the 
> type.getJavaClass() ; and
>  



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

[jira] [Deleted] (JENA-1614) When registering an incompatible Datatype a warning should be logged

[Claude Warren (JIRA)]

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

Claude Warren deleted JENA-1614:



> When registering an incompatible Datatype a warning should be logged
> 
>
> Key: JENA-1614
> URL: https://issues.apache.org/jira/browse/JENA-1614
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
>
> Classes that extend AdhocDatatype (or Basedatatype) and want to allow 
> multiple instances of the datatype class to be considered equal must do the 
> following:
>  # Override BaseDatatype.isEqual(LiteralLabel litLabel1, LiteralLabel 
> litLabel2) to call isEqualByTerm(LiteralLabel litLabel1, LiteralLabel 
> litLabel2).
>  # Override Object.equals(Object obj)
>  # Override Object.hashCode(), potentially calling BaseDatatype.getHashCode( 
> LiteralLabel lit )
> There should be a warning in the log if TypeMapper.register(RDFDatatype type 
> ) is called and:
>  # There is an existing datatype registered for the type.getJavaClass() ; and
>  # There registered type.isEquals( type.registeredType ) is false.
>  



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

[jira] [Assigned] (JENA-1613) When registering an incompatible Datatype a warning should be logged

[Claude Warren (JIRA)]

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

Claude Warren reassigned JENA-1613:
---

Assignee: Claude Warren

> When registering an incompatible Datatype a warning should be logged
> 
>
> Key: JENA-1613
> URL: https://issues.apache.org/jira/browse/JENA-1613
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: Jena 3.8.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
>
> Classes that extend AdhocDatatype (or Basedatatype) and want to allow 
> multiple instances of the datatype class to be considered equal must do the 
> following:
>  # Override BaseDatatype.isEqual(LiteralLabel litLabel1, LiteralLabel 
> litLabel2) to call isEqualByTerm(LiteralLabel litLabel1, LiteralLabel 
> litLabel2).
>  # Override Object.equals(Object obj)
>  # Override Object.hashCode(), potentially calling BaseDatatype.getHashCode( 
> LiteralLabel lit )
> There should be a warning in the log if TypeMapper.register(RDFDatatype type 
> ) is called and:
>  # There is an existing datatype registered for the type.getJavaClass() ; and
>  # There registered type.isEquals( type.registeredType ) is false.
>  



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

[jira] [Created] (JENA-1614) When registering an incompatible Datatype a warning should be logged

[Claude Warren (JIRA)]

Claude Warren created JENA-1614:
---

 Summary: When registering an incompatible Datatype a warning 
should be logged
 Key: JENA-1614
 URL: https://issues.apache.org/jira/browse/JENA-1614
 Project: Apache Jena
  Issue Type: Improvement
  Components: Core
Affects Versions: Jena 3.8.0
Reporter: Claude Warren
Assignee: Claude Warren


Classes that extend AdhocDatatype (or Basedatatype) and want to allow multiple 
instances of the datatype class to be considered equal must do the following:
 # Override BaseDatatype.isEqual(LiteralLabel litLabel1, LiteralLabel 
litLabel2) to call isEqualByTerm(LiteralLabel litLabel1, LiteralLabel 
litLabel2).
 # Override Object.equals(Object obj)
 # Override Object.hashCode(), potentially calling BaseDatatype.getHashCode( 
LiteralLabel lit )


There should be a warning in the log if TypeMapper.register(RDFDatatype type ) 
is called and:
 # There is an existing datatype registered for the type.getJavaClass() ; and
 # There registered type.isEquals( type.registeredType ) is false.

 



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

[jira] [Created] (JENA-1613) When registering an incompatible Datatype a warning should be logged

[Claude Warren (JIRA)]

Claude Warren created JENA-1613:
---

 Summary: When registering an incompatible Datatype a warning 
should be logged
 Key: JENA-1613
 URL: https://issues.apache.org/jira/browse/JENA-1613
 Project: Apache Jena
  Issue Type: Improvement
  Components: Core
Affects Versions: Jena 3.8.0
Reporter: Claude Warren


Classes that extend AdhocDatatype (or Basedatatype) and want to allow multiple 
instances of the datatype class to be considered equal must do the following:
 # Override BaseDatatype.isEqual(LiteralLabel litLabel1, LiteralLabel 
litLabel2) to call isEqualByTerm(LiteralLabel litLabel1, LiteralLabel 
litLabel2).
 # Override Object.equals(Object obj)
 # Override Object.hashCode(), potentially calling BaseDatatype.getHashCode( 
LiteralLabel lit )


There should be a warning in the log if TypeMapper.register(RDFDatatype type ) 
is called and:
 # There is an existing datatype registered for the type.getJavaClass() ; and
 # There registered type.isEquals( type.registeredType ) is false.

 



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

[jira] [Created] (JENA-1602) Update builder has no mechanism to add inserts or deletes based on model or triple collections

[Claude Warren (JIRA)]

Claude Warren created JENA-1602:
---

 Summary: Update builder has no mechanism to add inserts or deletes 
based on model or triple collections
 Key: JENA-1602
 URL: https://issues.apache.org/jira/browse/JENA-1602
 Project: Apache Jena
  Issue Type: Improvement
  Components: QueryBuilder
Reporter: Claude Warren
Assignee: Claude Warren


Currently the query builder allows insert/delete of single triples, this change 
would be  to accept a model as a collection of triples to insert/delete.  In 
addition a collection of  could be added/deleted.



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

[jira] [Resolved] (JENA-1567) Trix deserialization does not respect default namepace

[Claude Warren (JIRA)]

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

Claude Warren resolved JENA-1567.
-
Resolution: Not A Problem

Closing as not a problem as the issue is with the underlying XML parser 
implementation.

> Trix deserialization does not respect default namepace
> --
>
> Key: JENA-1567
> URL: https://issues.apache.org/jira/browse/JENA-1567
> Project: Apache Jena
>  Issue Type: Bug
>  Components: RIOT
>Affects Versions: Jena 3.6.0, Jena 3.7.0, Jena 3.8.0
>Reporter: Claude Warren
>Priority: Minor
> Attachments: Y.java
>
>
> TriX output serialized by jena will produce xml that uses the default 
> namespace.
> http://www.w3.org/2004/03/trix/trix-1/;>
>        
>   
>     
> urn:publicid:example.com:Device;67a2a324-cb08-30b2-b02d-096eceee933b;172.21.23.16
>     [http://purl.org/dc/elements/1.1/title]
>      datatype="http://www.w3.org/2001/XMLSchema#string;>172.21.23.16
>   
>    
>   
>  
> When the ReaderTrix class attempts to deserialize the xml the "datatype" 
> attribute namespace is not properly detected.
>  
> This appears to be in the  
> {{private String attribute(XMLStreamReader parser, String nsURI, String 
> localname)}}
>  
> The problem appears to be that parser.getAttributePrefix() returns an empty 
> string and parser.getAttributeNamespace() returns an emptry string (Not NULL) 
> so we don't call parser.getName().getNamespaceURI() to set the attrNS value 
> so the equality check fails and we throw an exception.
> I think that checking for "" should be added to the null check though " " 
> should also probably call the parser.getName().getNamespaceURI() method.
>  



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

[jira] [Commented] (JENA-1567) Trix deserialization does not respect default namepace

[Claude Warren (JIRA)]

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

Claude Warren commented on JENA-1567:
-

changing to minor status as the problem is an incorrectly implemented 3rd party 
SAX parser.

 

There is a potential work around by using:

{{System.setProperty( XMLInputFactory.class.getName() , 
"com.sun.xml.internal.stream.XMLInputFactoryImpl" );}}
{{  }}

Question remains, should we work around the defect?

 

> Trix deserialization does not respect default namepace
> --
>
> Key: JENA-1567
> URL: https://issues.apache.org/jira/browse/JENA-1567
> Project: Apache Jena
>  Issue Type: Bug
>  Components: RIOT
>Affects Versions: Jena 3.6.0, Jena 3.7.0, Jena 3.8.0
>Reporter: Claude Warren
>Priority: Minor
> Attachments: Y.java
>
>
> TriX output serialized by jena will produce xml that uses the default 
> namespace.
> http://www.w3.org/2004/03/trix/trix-1/;>
>        
>   
>     
> urn:publicid:example.com:Device;67a2a324-cb08-30b2-b02d-096eceee933b;172.21.23.16
>     [http://purl.org/dc/elements/1.1/title]
>      datatype="http://www.w3.org/2001/XMLSchema#string;>172.21.23.16
>   
>    
>   
>  
> When the ReaderTrix class attempts to deserialize the xml the "datatype" 
> attribute namespace is not properly detected.
>  
> This appears to be in the  
> {{private String attribute(XMLStreamReader parser, String nsURI, String 
> localname)}}
>  
> The problem appears to be that parser.getAttributePrefix() returns an empty 
> string and parser.getAttributeNamespace() returns an emptry string (Not NULL) 
> so we don't call parser.getName().getNamespaceURI() to set the attrNS value 
> so the equality check fails and we throw an exception.
> I think that checking for "" should be added to the null check though " " 
> should also probably call the parser.getName().getNamespaceURI() method.
>  



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

[jira] [Updated] (JENA-1567) Trix deserialization does not respect default namepace

[Claude Warren (JIRA)]

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

Claude Warren updated JENA-1567:

Priority: Minor  (was: Major)

> Trix deserialization does not respect default namepace
> --
>
> Key: JENA-1567
> URL: https://issues.apache.org/jira/browse/JENA-1567
> Project: Apache Jena
>  Issue Type: Bug
>  Components: RIOT
>Affects Versions: Jena 3.6.0, Jena 3.7.0, Jena 3.8.0
>Reporter: Claude Warren
>Priority: Minor
> Attachments: Y.java
>
>
> TriX output serialized by jena will produce xml that uses the default 
> namespace.
> http://www.w3.org/2004/03/trix/trix-1/;>
>        
>   
>     
> urn:publicid:example.com:Device;67a2a324-cb08-30b2-b02d-096eceee933b;172.21.23.16
>     [http://purl.org/dc/elements/1.1/title]
>      datatype="http://www.w3.org/2001/XMLSchema#string;>172.21.23.16
>   
>    
>   
>  
> When the ReaderTrix class attempts to deserialize the xml the "datatype" 
> attribute namespace is not properly detected.
>  
> This appears to be in the  
> {{private String attribute(XMLStreamReader parser, String nsURI, String 
> localname)}}
>  
> The problem appears to be that parser.getAttributePrefix() returns an empty 
> string and parser.getAttributeNamespace() returns an emptry string (Not NULL) 
> so we don't call parser.getName().getNamespaceURI() to set the attrNS value 
> so the equality check fails and we throw an exception.
> I think that checking for "" should be added to the null check though " " 
> should also probably call the parser.getName().getNamespaceURI() method.
>  



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

[jira] [Commented] (JENA-1567) Trix deserialization does not respect default namepace

[Claude Warren (JIRA)]

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

Claude Warren commented on JENA-1567:
-

Upon further investigation this looks like a but in woodstocks-core.  as the 
default namespace should not apply to attributes names and they are returning 
the empty string not null for no value.  However, perhaps we should consider if 
we want to account for the case where a parser returns the default namespace 
rather than null for the value of unprefixed attributes.

 

> Trix deserialization does not respect default namepace
> --
>
> Key: JENA-1567
> URL: https://issues.apache.org/jira/browse/JENA-1567
> Project: Apache Jena
>  Issue Type: Bug
>  Components: RIOT
>Affects Versions: Jena 3.6.0, Jena 3.7.0, Jena 3.8.0
>Reporter: Claude Warren
>Priority: Major
> Attachments: Y.java
>
>
> TriX output serialized by jena will produce xml that uses the default 
> namespace.
> http://www.w3.org/2004/03/trix/trix-1/;>
>        
>   
>     
> urn:publicid:example.com:Device;67a2a324-cb08-30b2-b02d-096eceee933b;172.21.23.16
>     [http://purl.org/dc/elements/1.1/title]
>      datatype="http://www.w3.org/2001/XMLSchema#string;>172.21.23.16
>   
>    
>   
>  
> When the ReaderTrix class attempts to deserialize the xml the "datatype" 
> attribute namespace is not properly detected.
>  
> This appears to be in the  
> {{private String attribute(XMLStreamReader parser, String nsURI, String 
> localname)}}
>  
> The problem appears to be that parser.getAttributePrefix() returns an empty 
> string and parser.getAttributeNamespace() returns an emptry string (Not NULL) 
> so we don't call parser.getName().getNamespaceURI() to set the attrNS value 
> so the equality check fails and we throw an exception.
> I think that checking for "" should be added to the null check though " " 
> should also probably call the parser.getName().getNamespaceURI() method.
>  



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

[jira] [Commented] (JENA-1567) Trix deserialization does not respect default namepace

[Claude Warren (JIRA)]

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

Claude Warren commented on JENA-1567:
-

adding:

 


    XMLInputFactory fac = XMLInputFactory.newInstance();
    System.out.println(  fac.getClass().getName() );
    System.out.println( fac.getProperty( XMLInputFactory.IS_NAMESPACE_AWARE 
) );

 

to the top of Y.main() yeilds

com.ctc.wstx.stax.WstxInputFactory
true

 

com.ctc.wstx.stax.WstxInputFactory seems to be included from 
woodstocks-core:5.0.3  as part of jackson-dataformat-xml (in my project)

 

> Trix deserialization does not respect default namepace
> --
>
> Key: JENA-1567
> URL: https://issues.apache.org/jira/browse/JENA-1567
> Project: Apache Jena
>  Issue Type: Bug
>  Components: RIOT
>Affects Versions: Jena 3.6.0, Jena 3.7.0, Jena 3.8.0
>Reporter: Claude Warren
>Priority: Major
> Attachments: Y.java
>
>
> TriX output serialized by jena will produce xml that uses the default 
> namespace.
> http://www.w3.org/2004/03/trix/trix-1/;>
>        
>   
>     
> urn:publicid:example.com:Device;67a2a324-cb08-30b2-b02d-096eceee933b;172.21.23.16
>     [http://purl.org/dc/elements/1.1/title]
>      datatype="http://www.w3.org/2001/XMLSchema#string;>172.21.23.16
>   
>    
>   
>  
> When the ReaderTrix class attempts to deserialize the xml the "datatype" 
> attribute namespace is not properly detected.
>  
> This appears to be in the  
> {{private String attribute(XMLStreamReader parser, String nsURI, String 
> localname)}}
>  
> The problem appears to be that parser.getAttributePrefix() returns an empty 
> string and parser.getAttributeNamespace() returns an emptry string (Not NULL) 
> so we don't call parser.getName().getNamespaceURI() to set the attrNS value 
> so the equality check fails and we throw an exception.
> I think that checking for "" should be added to the null check though " " 
> should also probably call the parser.getName().getNamespaceURI() method.
>  



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

[jira] [Commented] (JENA-1567) Trix deserialization does not respect default namepace

[Claude Warren (JIRA)]

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

Claude Warren commented on JENA-1567:
-

I get:


14:46:39.861 [main] ERROR org.apache.jena.riot - [line: 6, col: 7 ] Unexpected 
attribute : :datatype at typedLiteral
Exception in thread "main" org.apache.jena.riot.RiotException: [line: 6, col: 7 
] Unexpected attribute : :datatype at typedLiteral
    at 
org.apache.jena.riot.system.ErrorHandlerFactory$ErrorHandlerStrict.error(ErrorHandlerFactory.java:194)
    at org.apache.jena.riot.lang.ReaderTriX.staxError(ReaderTriX.java:429)
    at org.apache.jena.riot.lang.ReaderTriX.staxError(ReaderTriX.java:425)
    at org.apache.jena.riot.lang.ReaderTriX.attribute(ReaderTriX.java:414)
    at org.apache.jena.riot.lang.ReaderTriX.term(ReaderTriX.java:298)
    at org.apache.jena.riot.lang.ReaderTriX.read(ReaderTriX.java:225)
    at org.apache.jena.riot.lang.ReaderTriX.read(ReaderTriX.java:101)
    at org.apache.jena.riot.RDFParser.read(RDFParser.java:334)
    at org.apache.jena.riot.RDFParser.parseNotUri(RDFParser.java:324)
    at org.apache.jena.riot.RDFParser.parse(RDFParser.java:273)
    at org.apache.jena.riot.RDFParser.parse(RDFParser.java:235)
    at org.apache.jena.riot.RDFParserBuilder.parse(RDFParserBuilder.java:510)
    at Y.main(Y.java:40)

 

 

> Trix deserialization does not respect default namepace
> --
>
> Key: JENA-1567
> URL: https://issues.apache.org/jira/browse/JENA-1567
> Project: Apache Jena
>  Issue Type: Bug
>  Components: RIOT
>Affects Versions: Jena 3.6.0, Jena 3.7.0, Jena 3.8.0
>Reporter: Claude Warren
>Priority: Major
> Attachments: Y.java
>
>
> TriX output serialized by jena will produce xml that uses the default 
> namespace.
> http://www.w3.org/2004/03/trix/trix-1/;>
>        
>   
>     
> urn:publicid:example.com:Device;67a2a324-cb08-30b2-b02d-096eceee933b;172.21.23.16
>     [http://purl.org/dc/elements/1.1/title]
>      datatype="http://www.w3.org/2001/XMLSchema#string;>172.21.23.16
>   
>    
>   
>  
> When the ReaderTrix class attempts to deserialize the xml the "datatype" 
> attribute namespace is not properly detected.
>  
> This appears to be in the  
> {{private String attribute(XMLStreamReader parser, String nsURI, String 
> localname)}}
>  
> The problem appears to be that parser.getAttributePrefix() returns an empty 
> string and parser.getAttributeNamespace() returns an emptry string (Not NULL) 
> so we don't call parser.getName().getNamespaceURI() to set the attrNS value 
> so the equality check fails and we throw an exception.
> I think that checking for "" should be added to the null check though " " 
> should also probably call the parser.getName().getNamespaceURI() method.
>  



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

[jira] [Commented] (JENA-1567) Trix deserialization does not respect default namepace

[Claude Warren (JIRA)]

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

Claude Warren commented on JENA-1567:
-

The issue is in the XML parser.

{{http://www.w3.org/2004/03/trix/trix-1/;>}}

defines the default namespace.

{{ }}

uses the default namespace for the datatype attribute.

Our code gets the namespace for the prefix ""

our code:

{{   String attrPX =  parser.getAttributePrefix(0) ;}}
{{    String attrNS =  parser.getAttributeNamespace(0) ;}}
{{    if ( attrNS == null )}}
{{    attrNS = parser.getName().getNamespaceURI() ;}}
{{    String attrLN = parser.getAttributeLocalName(0) ;}}
{{    if ( ! Objects.equals(nsURI, attrNS) || ! Objects.equals(attrLN, 
localname) ) {}}
{{    staxError(parser.getLocation(), "Unexpected attribute : 
"+attrPX+":"+attrLN+" at "+tagName(parser)) ;}}
{{    }}}

 

parser.getAttributeNamespace(0) returns the empty string ("")

so the later if test:

{{Objects.equals(nsURI, attrNS)}}

fails and the staxError is called.

As I recall, XML parsers have an intersting problem with default namespaces are 
used in the attributes in that some can not distinguish between the default 
namespace and no namespace.

The solution is to modify

if ( attrNS == null )

to read

if ( attrNS == null || attrNS.equals(""))

I will attempt this fix as soon as I can.  I have to update my git copy of the 
code and make sure I can submit a proper patch.

 

> Trix deserialization does not respect default namepace
> --
>
> Key: JENA-1567
> URL: https://issues.apache.org/jira/browse/JENA-1567
> Project: Apache Jena
>  Issue Type: Bug
>  Components: RIOT
>Affects Versions: Jena 3.6.0, Jena 3.7.0, Jena 3.8.0
>Reporter: Claude Warren
>Priority: Major
> Attachments: Y.java
>
>
> TriX output serialized by jena will produce xml that uses the default 
> namespace.
> http://www.w3.org/2004/03/trix/trix-1/;>
>        
>   
>     
> urn:publicid:example.com:Device;67a2a324-cb08-30b2-b02d-096eceee933b;172.21.23.16
>     [http://purl.org/dc/elements/1.1/title]
>      datatype="http://www.w3.org/2001/XMLSchema#string;>172.21.23.16
>   
>    
>   
>  
> When the ReaderTrix class attempts to deserialize the xml the "datatype" 
> attribute namespace is not properly detected.
>  
> This appears to be in the  
> {{private String attribute(XMLStreamReader parser, String nsURI, String 
> localname)}}
>  
> The problem appears to be that parser.getAttributePrefix() returns an empty 
> string and parser.getAttributeNamespace() returns an emptry string (Not NULL) 
> so we don't call parser.getName().getNamespaceURI() to set the attrNS value 
> so the equality check fails and we throw an exception.
> I think that checking for "" should be added to the null check though " " 
> should also probably call the parser.getName().getNamespaceURI() method.
>  



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

[jira] [Updated] (JENA-1567) Trix deserialization does not respect default namepace

[Claude Warren (JIRA)]

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

Claude Warren updated JENA-1567:

Description: 
TriX output serialized by jena will produce xml that uses the default namespace.

http://www.w3.org/2004/03/trix/trix-1/;>
       
  
    
urn:publicid:example.com:Device;67a2a324-cb08-30b2-b02d-096eceee933b;172.21.23.16
    [http://purl.org/dc/elements/1.1/title]
    http://www.w3.org/2001/XMLSchema#string;>172.21.23.16
  
   
  

 

When the ReaderTrix class attempts to deserialize the xml the "datatype" 
attribute namespace is not properly detected.

 

This appears to be in the  

{{private String attribute(XMLStreamReader parser, String nsURI, String 
localname)}}

 

The problem appears to be that parser.getAttributePrefix() returns an empty 
string and parser.getAttributeNamespace() returns an emptry string (Not NULL) 
so we don't call parser.getName().getNamespaceURI() to set the attrNS value so 
the equality check fails and we throw an exception.

I think that checking for "" should be added to the null check though " " 
should also probably call the parser.getName().getNamespaceURI() method.

 

  was:
TriX output serialized by jena will produce xml that uses the default namespace.

{{http://www.w3.org/2004/03/trix/trix-1/;>}}
{{       }}
{{     }}
{{   
urn:publicid:example.com:Device;67a2a324-cb08-30b2-b02d-096eceee933b;172.21.23.16}}
{{   [http://purl.org/dc/elements/1.1/title]}}
{{   http://www.w3.org/2001/XMLSchema#string;>172.21.23.16}}
{{     }}
{{   }}
{{ }}

 

When the ReaderTrix class attempts to deserialize the xml the "datatype" 
attribute namespace is not properly detected.

 

This appears to be in the  

{{private String attribute(XMLStreamReader parser, String nsURI, String 
localname)}}

 

The problem appears to be that parser.getAttributePrefix() returns an empty 
string and parser.getAttributeNamespace() returns an emptry string (Not NULL) 
so we don't call parser.getName().getNamespaceURI() to set the attrNS value so 
the equality check fails and we throw an exception.

I think that checking for "" should be added to the null check though " " 
should also probably call the parser.getName().getNamespaceURI() method.

 


> Trix deserialization does not respect default namepace
> --
>
> Key: JENA-1567
> URL: https://issues.apache.org/jira/browse/JENA-1567
> Project: Apache Jena
>  Issue Type: Bug
>  Components: RIOT
>Affects Versions: Jena 3.6.0, Jena 3.7.0, Jena 3.8.0
>Reporter: Claude Warren
>Priority: Major
> Attachments: Y.java
>
>
> TriX output serialized by jena will produce xml that uses the default 
> namespace.
> http://www.w3.org/2004/03/trix/trix-1/;>
>        
>   
>     
> urn:publicid:example.com:Device;67a2a324-cb08-30b2-b02d-096eceee933b;172.21.23.16
>     [http://purl.org/dc/elements/1.1/title]
>      datatype="http://www.w3.org/2001/XMLSchema#string;>172.21.23.16
>   
>    
>   
>  
> When the ReaderTrix class attempts to deserialize the xml the "datatype" 
> attribute namespace is not properly detected.
>  
> This appears to be in the  
> {{private String attribute(XMLStreamReader parser, String nsURI, String 
> localname)}}
>  
> The problem appears to be that parser.getAttributePrefix() returns an empty 
> string and parser.getAttributeNamespace() returns an emptry string (Not NULL) 
> so we don't call parser.getName().getNamespaceURI() to set the attrNS value 
> so the equality check fails and we throw an exception.
> I think that checking for "" should be added to the null check though " " 
> should also probably call the parser.getName().getNamespaceURI() method.
>  



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

[jira] [Created] (JENA-1567) Trix deserialization does not respect default namepace

[Claude Warren (JIRA)]

Claude Warren created JENA-1567:
---

 Summary: Trix deserialization does not respect default namepace
 Key: JENA-1567
 URL: https://issues.apache.org/jira/browse/JENA-1567
 Project: Apache Jena
  Issue Type: Bug
  Components: RIOT
Affects Versions: Jena 3.7.0, Jena 3.6.0, Jena 3.8.0
Reporter: Claude Warren
 Attachments: Y.java

TriX output serialized by jena will produce xml that uses the default namespace.

{{http://www.w3.org/2004/03/trix/trix-1/;>}}
{{       }}
{{     }}
{{   
urn:publicid:example.com:Device;67a2a324-cb08-30b2-b02d-096eceee933b;172.21.23.16}}
{{   [http://purl.org/dc/elements/1.1/title]}}
{{   http://www.w3.org/2001/XMLSchema#string;>172.21.23.16}}
{{     }}
{{   }}
{{ }}

 

When the ReaderTrix class attempts to deserialize the xml the "datatype" 
attribute namespace is not properly detected.

 

This appears to be in the  

{{private String attribute(XMLStreamReader parser, String nsURI, String 
localname)}}

 

The problem appears to be that parser.getAttributePrefix() returns an empty 
string and parser.getAttributeNamespace() returns an emptry string (Not NULL) 
so we don't call parser.getName().getNamespaceURI() to set the attrNS value so 
the equality check fails and we throw an exception.

I think that checking for "" should be added to the null check though " " 
should also probably call the parser.getName().getNamespaceURI() method.

 



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

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

[Claude Warren (JIRA)]

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

Claude Warren commented on JENA-1514:
-

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

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




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

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


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



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

[jira] [Updated] (JENA-1515) Values added to subQuery are stripped by QueryBuilder

[Claude Warren (JIRA)]

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

Claude Warren updated JENA-1515:

Priority: Minor  (was: Major)

> Values added to subQuery are stripped by QueryBuilder
> -
>
> Key: JENA-1515
> URL: https://issues.apache.org/jira/browse/JENA-1515
> Project: Apache Jena
>  Issue Type: Bug
>  Components: QueryBuilder
>Affects Versions: Jena 3.6.0, Jena 3.7.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
>
> If values are added to a subQuery via the addValue methods the values are 
> stripped when the subquery is added to the outer query.
>  



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

[jira] [Created] (JENA-1515) Values added to subQuery are stripped by QueryBuilder

[Claude Warren (JIRA)]

Claude Warren created JENA-1515:
---

 Summary: Values added to subQuery are stripped by QueryBuilder
 Key: JENA-1515
 URL: https://issues.apache.org/jira/browse/JENA-1515
 Project: Apache Jena
  Issue Type: Bug
  Components: QueryBuilder
Affects Versions: Jena 3.6.0, Jena 3.7.0
Reporter: Claude Warren
Assignee: Claude Warren


If values are added to a subQuery via the addValue methods the values are 
stripped when the subquery is added to the outer query.

 



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

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

[Claude Warren (JIRA)]

Claude Warren created JENA-1514:
---

 Summary: Class cast exception with BigInteger literals.
 Key: JENA-1514
 URL: https://issues.apache.org/jira/browse/JENA-1514
 Project: Apache Jena
  Issue Type: Bug
  Components: Jena
Affects Versions: Jena 3.6.0, Jena 3.7.0
Reporter: Claude Warren
 Attachments: BigIntIssue.java

When saving a BigInteger as a literal it is converted into an 
XSDBaseNumericType.

When that  type is read back it is converted into the smallest numeric data 
type that can hold the value; a narrowing if you will.

While  this works fine for primitive and primitive wrapping types (e.g. int and 
Integer) there is no automatic boxing available for BigInteger so attempting to 
retrieve the value of a BigInteger that is smaller than the Long.MAX_VALUE will 
result in a class cast exception when the primitive type is cast to the 
BigInteger.

I suspect the similar issues arise when BigDecimal is also used but I have not 
tested.

Should we address this issue by creating a BigInteger and BigDecimal type that 
perhaps extends XSDBaseNumericType?  Should we address this issue at all and 
just post a warning?

Test code is included to show the issue.

 



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

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

[Claude Warren (JIRA)]

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

Claude Warren updated JENA-1514:

Attachment: BigIntIssue.java

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



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

[jira] [Resolved] (JENA-1509) RDFConnectionRemote does not execute update( UpdateRequest )

[Claude Warren (JIRA)]

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

Claude Warren resolved JENA-1509.
-
   Resolution: Fixed
Fix Version/s: Jena 3.7.0

> RDFConnectionRemote does not execute update( UpdateRequest )
> 
>
> Key: JENA-1509
> URL: https://issues.apache.org/jira/browse/JENA-1509
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Jena
>Affects Versions: Jena 3.7.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Major
> Fix For: Jena 3.7.0
>
>
> If an UpdateRequest is constructed and passed to the 
> RDFConnectionRemote.update() method the string value is lost and the results 
> is an "update string may not be null" exception.
>  
>  
>  



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

[jira] [Assigned] (JENA-1509) RDFConnectionRemote does not execute update( UpdateRequest )

[Claude Warren (JIRA)]

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

Claude Warren reassigned JENA-1509:
---

Assignee: Claude Warren

> RDFConnectionRemote does not execute update( UpdateRequest )
> 
>
> Key: JENA-1509
> URL: https://issues.apache.org/jira/browse/JENA-1509
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Jena
>Affects Versions: Jena 3.7.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Major
>
> If an UpdateRequest is constructed and passed to the 
> RDFConnectionRemote.update() method the string value is lost and the results 
> is an "update string may not be null" exception.
>  
>  
>  



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

[jira] [Created] (JENA-1509) RDFConnectionRemote does not execute update( UpdateRequest )

[Claude Warren (JIRA)]

Claude Warren created JENA-1509:
---

 Summary: RDFConnectionRemote does not execute update( 
UpdateRequest )
 Key: JENA-1509
 URL: https://issues.apache.org/jira/browse/JENA-1509
 Project: Apache Jena
  Issue Type: Bug
  Components: Jena
Affects Versions: Jena 3.7.0
Reporter: Claude Warren


If an UpdateRequest is constructed and passed to the 
RDFConnectionRemote.update() method the string value is lost and the results is 
an "update string may not be null" exception.

 

 

 



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

[jira] [Resolved] (JENA-1457) Graph contract tests do not properly support transactions

[Claude Warren (JIRA)]

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

Claude Warren resolved JENA-1457.
-
   Resolution: Fixed
Fix Version/s: Jena 3.7.0

> Graph contract tests do not properly support transactions
> -
>
> Key: JENA-1457
> URL: https://issues.apache.org/jira/browse/JENA-1457
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Core
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
> Fix For: Jena 3.7.0
>
>
> The Contract test for Graphs do not properly support transactions.  
> Specifically, if the graph supports transactions all actions should be 
> enclosed within a transaction.
> The easiest test for this is to test the GraphTxnTDB implementation as it 
> will fail if transactions are not properly used.



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

[jira] [Assigned] (JENA-1457) Graph contract tests do not properly support transactions

[Claude Warren (JIRA)]

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

Claude Warren reassigned JENA-1457:
---

Assignee: Claude Warren

> Graph contract tests do not properly support transactions
> -
>
> Key: JENA-1457
> URL: https://issues.apache.org/jira/browse/JENA-1457
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Core
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
>
> The Contract test for Graphs do not properly support transactions.  
> Specifically, if the graph supports transactions all actions should be 
> enclosed within a transaction.
> The easiest test for this is to test the GraphTxnTDB implementation as it 
> will fail if transactions are not properly used.



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

[jira] [Created] (JENA-1469) GraphTxnTDB does not handle abort() properly

[Claude Warren (JIRA)]

Claude Warren created JENA-1469:
---

 Summary: GraphTxnTDB does not handle abort() properly
 Key: JENA-1469
 URL: https://issues.apache.org/jira/browse/JENA-1469
 Project: Apache Jena
  Issue Type: Bug
  Components: TDB
Affects Versions: Jena 3.7.0
Reporter: Claude Warren
 Attachments: TDBGraphTxnTest.java

If, when in a transaction, an instance of GraphTxnTDB calls abort() and 
subsquently calls begin() an "Existing active write transaction"  
TDBTransactionException is thrown.

 

Example JUnit test is attached.

 

 

 



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

[jira] [Commented] (JENA-1457) Graph contract tests do not properly support transactions

[Claude Warren (JIRA)]

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

Claude Warren commented on JENA-1457:
-

the txnBegin and other methods determine if the graph supports transactions and 
uses them otherwise no transaction code is called.

> Graph contract tests do not properly support transactions
> -
>
> Key: JENA-1457
> URL: https://issues.apache.org/jira/browse/JENA-1457
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Core
>Reporter: Claude Warren
>Priority: Minor
>
> The Contract test for Graphs do not properly support transactions.  
> Specifically, if the graph supports transactions all actions should be 
> enclosed within a transaction.
> The easiest test for this is to test the GraphTxnTDB implementation as it 
> will fail if transactions are not properly used.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (JENA-1457) Graph contract tests do not properly support transactions

[Claude Warren (JIRA)]

Claude Warren created JENA-1457:
---

 Summary: Graph contract tests do not properly support transactions
 Key: JENA-1457
 URL: https://issues.apache.org/jira/browse/JENA-1457
 Project: Apache Jena
  Issue Type: Bug
  Components: Core
Reporter: Claude Warren
Priority: Minor


The Contract test for Graphs do not properly support transactions.  
Specifically, if the graph supports transactions all actions should be enclosed 
within a transaction.

The easiest test for this is to test the GraphTxnTDB implementation as it will 
fail if transactions are not properly used.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (JENA-1456) QueryBuilder needs a stand alone WhereClause instance

[Claude Warren (JIRA)]

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

Claude Warren resolved JENA-1456.
-
   Resolution: Fixed
Fix Version/s: Jena 3.7.0

WhereBuilder created.  Has all the functions for building where clauses that 
may be added to other builders.

> QueryBuilder needs a stand alone  WhereClause instance
> --
>
> Key: JENA-1456
> URL: https://issues.apache.org/jira/browse/JENA-1456
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: QueryBuilder
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
> Fix For: Jena 3.7.0
>
>
> Various QueryBuilders have methods that  take a WhereClause instance however, 
> there is no standalone implementation of WhereClause.  
> This improvement is to create a standalone WhereBuilder that will create a 
> WhereClause (and required interfaces) instance without the interfaces 
> associated with the general query builders.
> This is nothing more than a convenience.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (JENA-1455) QueryBuilder allows Node_Variable instances into QueryTripleIterator

[Claude Warren (JIRA)]

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

Claude Warren resolved JENA-1455.
-
   Resolution: Fixed
Fix Version/s: Jena 3.7.0

Added additional checks and processing of quads and triples when queries are 
being built.

> QueryBuilder allows Node_Variable instances into QueryTripleIterator
> 
>
> Key: JENA-1455
> URL: https://issues.apache.org/jira/browse/JENA-1455
> Project: Apache Jena
>  Issue Type: Bug
>  Components: QueryBuilder
>Affects Versions: Jena 3.6.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
> Fix For: Jena 3.7.0
>
>
> Using Node_Variable instances in Quads and Triples to to methods results in 
> Node_Variable instances appearing in the QueryTripleIterator.
> QueryTripleIterator at line 87 calls Var.isVar(node) which throws an 
> exception if the node is a Node_Variable.  But based code following line 87 I 
> think that Node_Variable should be accepted.
> {noformat}
> private static Node substitute(Node node, Binding binding)
> {
> if ( Var.isVar(node) ) // < line 87
> {
> Node x = binding.get(Var.alloc(node)) ;
> if ( x != null )
> return x ;
> }
> return node ;
> }
> {noformat}
> QueryTripleIterator is internal code and is only expecting Var instances.  
> The solution is to fix the QueryBuilder code so that it only produces Var in 
> the queries resulting from a build() execution.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (JENA-1456) QueryBuilder needs a stand alone WhereClause instance

[Claude Warren (JIRA)]

Claude Warren created JENA-1456:
---

 Summary: QueryBuilder needs a stand alone  WhereClause instance
 Key: JENA-1456
 URL: https://issues.apache.org/jira/browse/JENA-1456
 Project: Apache Jena
  Issue Type: Improvement
  Components: QueryBuilder
Reporter: Claude Warren
Assignee: Claude Warren
Priority: Minor


Various QueryBuilders have methods that  take a WhereClause instance however, 
there is no standalone implementation of WhereClause.  

This improvement is to create a standalone WhereBuilder that will create a 
WhereClause (and required interfaces) instance without the interfaces 
associated with the general query builders.

This is nothing more than a convenience.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (JENA-1442) QueryBuilder ValuesClause.clearValues does not return the builder

[Claude Warren (JIRA)]

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

Claude Warren resolved JENA-1442.
-
   Resolution: Fixed
Fix Version/s: Jena 3.6.0

Changed return value from void to builder type.  Code checked in and tested.

> QueryBuilder ValuesClause.clearValues does not return the builder
> -
>
> Key: JENA-1442
> URL: https://issues.apache.org/jira/browse/JENA-1442
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: QueryBuilder
>Affects Versions: Jena 3.5.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
> Fix For: Jena 3.6.0
>
>
> This is just an issue for fluent usage.  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (JENA-1442) QueryBuilder ValuesClause.clearValues does not return the builder

[Claude Warren (JIRA)]

Claude Warren created JENA-1442:
---

 Summary: QueryBuilder ValuesClause.clearValues does not return the 
builder
 Key: JENA-1442
 URL: https://issues.apache.org/jira/browse/JENA-1442
 Project: Apache Jena
  Issue Type: Improvement
  Components: QueryBuilder
Affects Versions: Jena 3.5.0
Reporter: Claude Warren
Assignee: Claude Warren
Priority: Minor


This is just an issue for fluent usage.  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (JENA-1433) Query Builder does not have a short hand method to add group clause with single triple

[Claude Warren (JIRA)]

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

Claude Warren resolved JENA-1433.
-
   Resolution: Resolved
Fix Version/s: Jena 3.6.0

> Query Builder does not have a short hand method to add group clause with 
> single triple
> --
>
> Key: JENA-1433
> URL: https://issues.apache.org/jira/browse/JENA-1433
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: QueryBuilder
>Affects Versions: Jena 3.5.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
> Fix For: Jena 3.6.0
>
>
> Currently query builder requires a subquery when adding a graph element.  
> This change is to create a short hand call to insert a graph with a single 
> triple path.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (JENA-1432) Query Builder does not have a mechanism to put value var block in the where clause

[Claude Warren (JIRA)]

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

Claude Warren closed JENA-1432.
---
   Resolution: Resolved
Fix Version/s: Jena 3.6.0

> Query Builder does not have a mechanism to put value var block in the where 
> clause
> --
>
> Key: JENA-1432
> URL: https://issues.apache.org/jira/browse/JENA-1432
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: QueryBuilder
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
> Fix For: Jena 3.6.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (JENA-1436) RDFConnection does not implement Closable interface

[Claude Warren (JIRA)]

Claude Warren created JENA-1436:
---

 Summary: RDFConnection does not implement Closable interface
 Key: JENA-1436
 URL: https://issues.apache.org/jira/browse/JENA-1436
 Project: Apache Jena
  Issue Type: Improvement
  Components: Jena
Affects Versions: Jena 3.5.0
Reporter: Claude Warren
Priority: Minor


RDFConnection implements the java.lang.AutoClosable interface but not the 
java.io.Closable interface.  As such the apache IOUtils.closeQuietly() does not 
work with an RDFConnection object.  I think that RDFConnection meets the 
requirements for Closable namely

A  Closable is a source or destination of data that can be closed.
The close method is invoked to release resources that the object is
 holding (such as open files).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (JENA-1433) Query Builder does not have a short hand method to add group clause with single triple

[Claude Warren (JIRA)]

Claude Warren created JENA-1433:
---

 Summary: Query Builder does not have a short hand method to add 
group clause with single triple
 Key: JENA-1433
 URL: https://issues.apache.org/jira/browse/JENA-1433
 Project: Apache Jena
  Issue Type: Improvement
  Components: QueryBuilder
Affects Versions: Jena 3.5.0
Reporter: Claude Warren
Assignee: Claude Warren
Priority: Minor


Currently query builder requires a subquery when adding a graph element.  This 
change is to create a short hand call to insert a graph with a single triple 
path.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (JENA-1432) Query Builder does not have a mechanism to put value var block in the where clause

[Claude Warren (JIRA)]

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

Claude Warren updated JENA-1432:

Issue Type: Improvement  (was: Bug)

> Query Builder does not have a mechanism to put value var block in the where 
> clause
> --
>
> Key: JENA-1432
> URL: https://issues.apache.org/jira/browse/JENA-1432
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: QueryBuilder
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (JENA-1432) Query Builder does not have a mechanism to put value var block in the where clause

[Claude Warren (JIRA)]

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

Claude Warren updated JENA-1432:

Summary: Query Builder does not have a mechanism to put value var block in 
the where clause  (was: Query Builder does not have a mechanism to put values 
in)

> Query Builder does not have a mechanism to put value var block in the where 
> clause
> --
>
> Key: JENA-1432
> URL: https://issues.apache.org/jira/browse/JENA-1432
> Project: Apache Jena
>  Issue Type: Bug
>  Components: QueryBuilder
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (JENA-1432) Query Builder does not have a mechanism to put values in

[Claude Warren (JIRA)]

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

Claude Warren reassigned JENA-1432:
---

   Assignee: Claude Warren
   Priority: Minor  (was: Major)
Component/s: QueryBuilder

Add the ability to add Values to where clause

ValueVar only adds block a  the end of the query (outside the where clause).

This change is to add Value var blocks inside the where clause.


> Query Builder does not have a mechanism to put values in
> 
>
> Key: JENA-1432
> URL: https://issues.apache.org/jira/browse/JENA-1432
> Project: Apache Jena
>  Issue Type: Bug
>  Components: QueryBuilder
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (JENA-1432) Query Builder does not have a mechanism to put values in

[Claude Warren (JIRA)]

Claude Warren created JENA-1432:
---

 Summary: Query Builder does not have a mechanism to put values in
 Key: JENA-1432
 URL: https://issues.apache.org/jira/browse/JENA-1432
 Project: Apache Jena
  Issue Type: Bug
Reporter: Claude Warren






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (JENA-1428) NPE in Query Builder

[Claude Warren (JIRA)]

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

Claude Warren resolved JENA-1428.
-
   Resolution: Fixed
Fix Version/s: Jena 3.6.0

Fixed AbstractRewriter to accept null parameter value.
Fixed NodeValueRewriter to call asNode() rather than getNode() on NodeValues.
Added tests.

Maven build passes.

> NPE in Query Builder
> 
>
> Key: JENA-1428
> URL: https://issues.apache.org/jira/browse/JENA-1428
> Project: Apache Jena
>  Issue Type: Bug
>  Components: QueryBuilder
>Affects Versions: Jena 3.4.0
>Reporter: Claude Warren
>Assignee: Claude Warren
> Fix For: Jena 3.6.0
>
>
> As reported by Chris Dollin on users mailing list:
> I was experimenting with the query builder and hit a problem
> when I was attempting to construct an Expr. This example:
> package com.epimorphics.scratch;
> import org.apache.jena.arq.querybuilder.ConstructBuilder;
> import org.apache.jena.sparql.expr.E_GreaterThan;
> import org.apache.jena.sparql.expr.Expr;
> import org.apache.jena.sparql.expr.ExprVar;
> import org.apache.jena.sparql.expr.nodevalue.NodeValueInteger;
> import org.junit.Test;
> public class Example {
> @Test public void tryBuilding() {
> ConstructBuilder cb = new ConstructBuilder();
> Expr x = new NodeValueInteger(1);
> Expr y = new ExprVar("y");
> Expr e = new E_GreaterThan(x, y);
> cb.addFilter(e);
> System.err.println(cb.buildString());
> }
> }
> when run fails with a null pointer exception:
> java.lang.NullPointerException
> at org.apache.jena.arq.querybuilder.rewriters.
> AbstractRewriter.changeNode(AbstractRewriter.java:126)
> at org.apache.jena.arq.querybuilder.rewriters.NodeValueRewriter.visit(
> NodeValueRewriter.java:64)
> at org.apache.jena.sparql.expr.nodevalue.NodeValueInteger.
> visit(NodeValueInteger.java:78)
> at org.apache.jena.arq.querybuilder.rewriters.ExprRewriter.visit(
> ExprRewriter.java:127)
> at org.apache.jena.sparql.expr.NodeValue.visit(NodeValue.java:1205)
> at org.apache.jena.arq.querybuilder.rewriters.ExprRewriter.visit(
> ExprRewriter.java:65)
> at org.apache.jena.sparql.expr.ExprFunction2.visit(
> ExprFunction2.java:109)
> at org.apache.jena.arq.querybuilder.rewriters.ElementRewriter.visit(
> ElementRewriter.java:70)
> at org.apache.jena.sparql.syntax.ElementFilter.visit(
> ElementFilter.java:35)
> at org.apache.jena.arq.querybuilder.rewriters.ElementRewriter.visit(
> ElementRewriter.java:141)
> at org.apache.jena.sparql.syntax.ElementGroup.visit(
> ElementGroup.java:120)
> at org.apache.jena.arq.querybuilder.handlers.WhereHandler.addAll(
> WhereHandler.java:81)
> at org.apache.jena.arq.querybuilder.handlers.HandlerBlock.addAll(
> HandlerBlock.java:218)
> at org.apache.jena.arq.querybuilder.handlers.HandlerBlock.addAll(
> HandlerBlock.java:245)
> at org.apache.jena.arq.querybuilder.AbstractQueryBuilder.build(
> AbstractQueryBuilder.java:555)
> at org.apache.jena.arq.querybuilder.AbstractQueryBuilder.buildString(
> AbstractQueryBuilder.java:522)
> at com.epimorphics.scratch.Example.tryBuilding(Example.java:20)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(
> FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(
> ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(
> FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.
> evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(
> BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(
> BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(
> JUnit4IdeaTestRunner.java:68)
> at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.
> 

[jira] [Commented] (JENA-1428) NPE in Query Builder

[Claude Warren (JIRA)]

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

Claude Warren commented on JENA-1428:
-

workaround
change:

Expr x = new NodeValueInteger(1)

to
NodeValue nv = new NodeValueInteger(1)
nv.asNode()
Expr x = nv;


> NPE in Query Builder
> 
>
> Key: JENA-1428
> URL: https://issues.apache.org/jira/browse/JENA-1428
> Project: Apache Jena
>  Issue Type: Bug
>  Components: QueryBuilder
>Affects Versions: Jena 3.4.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>
> As reported by Chris Dollin on users mailing list:
> I was experimenting with the query builder and hit a problem
> when I was attempting to construct an Expr. This example:
> package com.epimorphics.scratch;
> import org.apache.jena.arq.querybuilder.ConstructBuilder;
> import org.apache.jena.sparql.expr.E_GreaterThan;
> import org.apache.jena.sparql.expr.Expr;
> import org.apache.jena.sparql.expr.ExprVar;
> import org.apache.jena.sparql.expr.nodevalue.NodeValueInteger;
> import org.junit.Test;
> public class Example {
> @Test public void tryBuilding() {
> ConstructBuilder cb = new ConstructBuilder();
> Expr x = new NodeValueInteger(1);
> Expr y = new ExprVar("y");
> Expr e = new E_GreaterThan(x, y);
> cb.addFilter(e);
> System.err.println(cb.buildString());
> }
> }
> when run fails with a null pointer exception:
> java.lang.NullPointerException
> at org.apache.jena.arq.querybuilder.rewriters.
> AbstractRewriter.changeNode(AbstractRewriter.java:126)
> at org.apache.jena.arq.querybuilder.rewriters.NodeValueRewriter.visit(
> NodeValueRewriter.java:64)
> at org.apache.jena.sparql.expr.nodevalue.NodeValueInteger.
> visit(NodeValueInteger.java:78)
> at org.apache.jena.arq.querybuilder.rewriters.ExprRewriter.visit(
> ExprRewriter.java:127)
> at org.apache.jena.sparql.expr.NodeValue.visit(NodeValue.java:1205)
> at org.apache.jena.arq.querybuilder.rewriters.ExprRewriter.visit(
> ExprRewriter.java:65)
> at org.apache.jena.sparql.expr.ExprFunction2.visit(
> ExprFunction2.java:109)
> at org.apache.jena.arq.querybuilder.rewriters.ElementRewriter.visit(
> ElementRewriter.java:70)
> at org.apache.jena.sparql.syntax.ElementFilter.visit(
> ElementFilter.java:35)
> at org.apache.jena.arq.querybuilder.rewriters.ElementRewriter.visit(
> ElementRewriter.java:141)
> at org.apache.jena.sparql.syntax.ElementGroup.visit(
> ElementGroup.java:120)
> at org.apache.jena.arq.querybuilder.handlers.WhereHandler.addAll(
> WhereHandler.java:81)
> at org.apache.jena.arq.querybuilder.handlers.HandlerBlock.addAll(
> HandlerBlock.java:218)
> at org.apache.jena.arq.querybuilder.handlers.HandlerBlock.addAll(
> HandlerBlock.java:245)
> at org.apache.jena.arq.querybuilder.AbstractQueryBuilder.build(
> AbstractQueryBuilder.java:555)
> at org.apache.jena.arq.querybuilder.AbstractQueryBuilder.buildString(
> AbstractQueryBuilder.java:522)
> at com.epimorphics.scratch.Example.tryBuilding(Example.java:20)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(
> FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(
> ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(
> FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.
> evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(
> BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(
> BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(
> JUnit4IdeaTestRunner.java:68)
> at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.
> startRunnerWithArgs(IdeaTestRunner.java:47)
> at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(
> 

[jira] [Commented] (JENA-1428) NPE in Query Builder

[Claude Warren (JIRA)]

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

Claude Warren commented on JENA-1428:
-

Issue is that NodeValueRewriter calls getNode() when it should call asNode() on 
the node value objects.


> NPE in Query Builder
> 
>
> Key: JENA-1428
> URL: https://issues.apache.org/jira/browse/JENA-1428
> Project: Apache Jena
>  Issue Type: Bug
>  Components: QueryBuilder
>Affects Versions: Jena 3.4.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>
> As reported by Chris Dollin on users mailing list:
> I was experimenting with the query builder and hit a problem
> when I was attempting to construct an Expr. This example:
> package com.epimorphics.scratch;
> import org.apache.jena.arq.querybuilder.ConstructBuilder;
> import org.apache.jena.sparql.expr.E_GreaterThan;
> import org.apache.jena.sparql.expr.Expr;
> import org.apache.jena.sparql.expr.ExprVar;
> import org.apache.jena.sparql.expr.nodevalue.NodeValueInteger;
> import org.junit.Test;
> public class Example {
> @Test public void tryBuilding() {
> ConstructBuilder cb = new ConstructBuilder();
> Expr x = new NodeValueInteger(1);
> Expr y = new ExprVar("y");
> Expr e = new E_GreaterThan(x, y);
> cb.addFilter(e);
> System.err.println(cb.buildString());
> }
> }
> when run fails with a null pointer exception:
> java.lang.NullPointerException
> at org.apache.jena.arq.querybuilder.rewriters.
> AbstractRewriter.changeNode(AbstractRewriter.java:126)
> at org.apache.jena.arq.querybuilder.rewriters.NodeValueRewriter.visit(
> NodeValueRewriter.java:64)
> at org.apache.jena.sparql.expr.nodevalue.NodeValueInteger.
> visit(NodeValueInteger.java:78)
> at org.apache.jena.arq.querybuilder.rewriters.ExprRewriter.visit(
> ExprRewriter.java:127)
> at org.apache.jena.sparql.expr.NodeValue.visit(NodeValue.java:1205)
> at org.apache.jena.arq.querybuilder.rewriters.ExprRewriter.visit(
> ExprRewriter.java:65)
> at org.apache.jena.sparql.expr.ExprFunction2.visit(
> ExprFunction2.java:109)
> at org.apache.jena.arq.querybuilder.rewriters.ElementRewriter.visit(
> ElementRewriter.java:70)
> at org.apache.jena.sparql.syntax.ElementFilter.visit(
> ElementFilter.java:35)
> at org.apache.jena.arq.querybuilder.rewriters.ElementRewriter.visit(
> ElementRewriter.java:141)
> at org.apache.jena.sparql.syntax.ElementGroup.visit(
> ElementGroup.java:120)
> at org.apache.jena.arq.querybuilder.handlers.WhereHandler.addAll(
> WhereHandler.java:81)
> at org.apache.jena.arq.querybuilder.handlers.HandlerBlock.addAll(
> HandlerBlock.java:218)
> at org.apache.jena.arq.querybuilder.handlers.HandlerBlock.addAll(
> HandlerBlock.java:245)
> at org.apache.jena.arq.querybuilder.AbstractQueryBuilder.build(
> AbstractQueryBuilder.java:555)
> at org.apache.jena.arq.querybuilder.AbstractQueryBuilder.buildString(
> AbstractQueryBuilder.java:522)
> at com.epimorphics.scratch.Example.tryBuilding(Example.java:20)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(
> FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(
> ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(
> FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.
> evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(
> BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(
> BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(
> JUnit4IdeaTestRunner.java:68)
> at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.
> startRunnerWithArgs(IdeaTestRunner.java:47)
> at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(
> JUnitStarter.java:242)
>

[jira] [Created] (JENA-1428) NPE in Query Builder

[Claude Warren (JIRA)]

Claude Warren created JENA-1428:
---

 Summary: NPE in Query Builder
 Key: JENA-1428
 URL: https://issues.apache.org/jira/browse/JENA-1428
 Project: Apache Jena
  Issue Type: Bug
  Components: QueryBuilder
Affects Versions: Jena 3.4.0
Reporter: Claude Warren
Assignee: Claude Warren


As reported by Chris Dollin on users mailing list:

I was experimenting with the query builder and hit a problem
when I was attempting to construct an Expr. This example:

package com.epimorphics.scratch;

import org.apache.jena.arq.querybuilder.ConstructBuilder;
import org.apache.jena.sparql.expr.E_GreaterThan;
import org.apache.jena.sparql.expr.Expr;
import org.apache.jena.sparql.expr.ExprVar;
import org.apache.jena.sparql.expr.nodevalue.NodeValueInteger;
import org.junit.Test;

public class Example {

@Test public void tryBuilding() {
ConstructBuilder cb = new ConstructBuilder();

Expr x = new NodeValueInteger(1);
Expr y = new ExprVar("y");
Expr e = new E_GreaterThan(x, y);
cb.addFilter(e);
System.err.println(cb.buildString());
}
}

when run fails with a null pointer exception:

java.lang.NullPointerException
at org.apache.jena.arq.querybuilder.rewriters.
AbstractRewriter.changeNode(AbstractRewriter.java:126)
at org.apache.jena.arq.querybuilder.rewriters.NodeValueRewriter.visit(
NodeValueRewriter.java:64)
at org.apache.jena.sparql.expr.nodevalue.NodeValueInteger.
visit(NodeValueInteger.java:78)
at org.apache.jena.arq.querybuilder.rewriters.ExprRewriter.visit(
ExprRewriter.java:127)
at org.apache.jena.sparql.expr.NodeValue.visit(NodeValue.java:1205)
at org.apache.jena.arq.querybuilder.rewriters.ExprRewriter.visit(
ExprRewriter.java:65)
at org.apache.jena.sparql.expr.ExprFunction2.visit(
ExprFunction2.java:109)
at org.apache.jena.arq.querybuilder.rewriters.ElementRewriter.visit(
ElementRewriter.java:70)
at org.apache.jena.sparql.syntax.ElementFilter.visit(
ElementFilter.java:35)
at org.apache.jena.arq.querybuilder.rewriters.ElementRewriter.visit(
ElementRewriter.java:141)
at org.apache.jena.sparql.syntax.ElementGroup.visit(
ElementGroup.java:120)
at org.apache.jena.arq.querybuilder.handlers.WhereHandler.addAll(
WhereHandler.java:81)
at org.apache.jena.arq.querybuilder.handlers.HandlerBlock.addAll(
HandlerBlock.java:218)
at org.apache.jena.arq.querybuilder.handlers.HandlerBlock.addAll(
HandlerBlock.java:245)
at org.apache.jena.arq.querybuilder.AbstractQueryBuilder.build(
AbstractQueryBuilder.java:555)
at org.apache.jena.arq.querybuilder.AbstractQueryBuilder.buildString(
AbstractQueryBuilder.java:522)
at com.epimorphics.scratch.Example.tryBuilding(Example.java:20)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(
FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(
ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(
FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.
evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(
BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(
BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(
JUnit4IdeaTestRunner.java:68)
at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.
startRunnerWithArgs(IdeaTestRunner.java:47)
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(
JUnitStarter.java:242)
at com.intellij.rt.execution.junit.JUnitStarter.main(
JUnitStarter.java:70)

Replacing the addFilter line with

cb.addFilter("1 > ?y");

does not fail, terminating with the expected print-out
of a construct query

   CONSTRUCT
{
}
  WHERE
{ FILTER ( 1 > ?y )}

I tried poking around with the debugger but couldn't see anyhting
obvious. However, /sometimes/ stepping through the code
results in it working and sometimes not, 

[jira] [Resolved] (JENA-1365) QueryBuilder can build an invalid union-of-one query.

[Claude Warren (JIRA)]

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

Claude Warren resolved JENA-1365.
-
   Resolution: Fixed
Fix Version/s: Jena 3.4.0

Updates completed and tested

> QueryBuilder can build an invalid union-of-one query.
> -
>
> Key: JENA-1365
> URL: https://issues.apache.org/jira/browse/JENA-1365
> Project: Apache Jena
>  Issue Type: Bug
>  Components: QueryBuilder
>Affects Versions: Jena 3.3.0
>Reporter: Claude Warren
>Assignee: Claude Warren
> Fix For: Jena 3.4.0
>
>
> From email chain betwen Claude and Andy
> is the union-of-one still legal during the construction of the query?
> Its illegal in a query - UNION is
> {..} UNION {..} UNION {..}
> The
> expected usage in the builder is:
> {noformat}
> builder.addUnion(  ).addUnion(
> )
> {noformat}
> Currently the code builds a union-of-one and adds the next union to it. 
> check to ensure that a union-of-one is not generated in the
> final result.
> At a minimum it an error to generate a union of one.
> So either, throw an expection or generate "{ pattern }" (including inside {}) 
> which is the moral equivalent.
> IMO The second is nicer.  Tat is what I changed the formatter to do so at 
> least it generated something even if it is changing the query a bit (round 
> trip checking will fail but then it fails currently as it can't be parsed at 
> all)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JENA-1365) QueryBuilder can build an invalid union-of-one query.

[Claude Warren (JIRA)]

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

Claude Warren commented on JENA-1365:
-

The tests work with the change to FormatterElement and I will check in the 
change soon, however I have a question.

Should the test not be  el.getElements().size() <= 1 to account for 
union-of-zero?

Claude

> QueryBuilder can build an invalid union-of-one query.
> -
>
> Key: JENA-1365
> URL: https://issues.apache.org/jira/browse/JENA-1365
> Project: Apache Jena
>  Issue Type: Bug
>  Components: QueryBuilder
>Affects Versions: Jena 3.3.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>
> From email chain betwen Claude and Andy
> is the union-of-one still legal during the construction of the query?
> Its illegal in a query - UNION is
> {..} UNION {..} UNION {..}
> The
> expected usage in the builder is:
> {noformat}
> builder.addUnion(  ).addUnion(
> )
> {noformat}
> Currently the code builds a union-of-one and adds the next union to it. 
> check to ensure that a union-of-one is not generated in the
> final result.
> At a minimum it an error to generate a union of one.
> So either, throw an expection or generate "{ pattern }" (including inside {}) 
> which is the moral equivalent.
> IMO The second is nicer.  Tat is what I changed the formatter to do so at 
> least it generated something even if it is changing the query a bit (round 
> trip checking will fail but then it fails currently as it can't be parsed at 
> all)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JENA-1365) QueryBuilder can build an invalid union-of-one query.

[Claude Warren (JIRA)]

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

Claude Warren commented on JENA-1365:
-

Andy mentions that the FormatterElement method for ElementUnion shoudl read.

 @Override
 public void visit(ElementUnion el) {
 if ( el.getElements().size() == 1 ) {
 // If this is an element of just one, just do it in-place
return ;
 } 


I wonder if this is wise.  QueryBuilder managed to build union-of-one queries 
and nothing generates an error when one is created.  If the formatter simply 
removes it from the display but it still exists in the Element tree that is 
executed how does a developer/user figure out that something is wrong or where 
that something is.

It is unfortunate that there are no comment lines in SPARQL as then the 
formatter could output the a message. :(


> QueryBuilder can build an invalid union-of-one query.
> -
>
> Key: JENA-1365
> URL: https://issues.apache.org/jira/browse/JENA-1365
> Project: Apache Jena
>  Issue Type: Bug
>  Components: QueryBuilder
>Affects Versions: Jena 3.3.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>
> From email chain betwen Claude and Andy
> is the union-of-one still legal during the construction of the query?
> Its illegal in a query - UNION is
> {..} UNION {..} UNION {..}
> The
> expected usage in the builder is:
> {noformat}
> builder.addUnion(  ).addUnion(
> )
> {noformat}
> Currently the code builds a union-of-one and adds the next union to it. 
> check to ensure that a union-of-one is not generated in the
> final result.
> At a minimum it an error to generate a union of one.
> So either, throw an expection or generate "{ pattern }" (including inside {}) 
> which is the moral equivalent.
> IMO The second is nicer.  Tat is what I changed the formatter to do so at 
> least it generated something even if it is changing the query a bit (round 
> trip checking will fail but then it fails currently as it can't be parsed at 
> all)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (JENA-1365) QueryBuilder can build an invalid union-of-one query.

[Claude Warren (JIRA)]

Claude Warren created JENA-1365:
---

 Summary: QueryBuilder can build an invalid union-of-one query.
 Key: JENA-1365
 URL: https://issues.apache.org/jira/browse/JENA-1365
 Project: Apache Jena
  Issue Type: Bug
  Components: QueryBuilder
Affects Versions: Jena 3.3.0
Reporter: Claude Warren
Assignee: Claude Warren


>From email chain betwen Claude and Andy



is the union-of-one still legal during the construction of the query?


Its illegal in a query - UNION is

{..} UNION {..} UNION {..}

The
expected usage in the builder is:

{noformat}
builder.addUnion(  ).addUnion(
)
{noformat}

Currently the code builds a union-of-one and adds the next union to it. 

check to ensure that a union-of-one is not generated in the
final result.


At a minimum it an error to generate a union of one.

So either, throw an expection or generate "{ pattern }" (including inside {}) 
which is the moral equivalent.

IMO The second is nicer.  Tat is what I changed the formatter to do so at least 
it generated something even if it is changing the query a bit (round trip 
checking will fail but then it fails currently as it can't be parsed at all)




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (JENA-1352) QueryBuilder should provide UpdateBuilder

[Claude Warren (JIRA)]

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

Claude Warren resolved JENA-1352.
-
   Resolution: Implemented
Fix Version/s: Jena 3.4.0

> QueryBuilder should provide UpdateBuilder
> -
>
> Key: JENA-1352
> URL: https://issues.apache.org/jira/browse/JENA-1352
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: QueryBuilder
>Affects Versions: Jena 3.3.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
> Fix For: Jena 3.4.0
>
>
> The QueryBuilder module should include an UpdateRequestBuilder that would 
> apply the same sort of functionality to creating UpdateRequests.
> The QueryBuilder framework will not work but should be extended to add 
> support for UpdateRequest while providing the same Object based API style.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (JENA-1358) UpdateRequest does not properly execute w3c update Example 10

[Claude Warren (JIRA)]

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

Claude Warren closed JENA-1358.
---
Resolution: Not A Problem

Issue was with data  in initial table.


> UpdateRequest does not properly execute w3c update Example 10
> -
>
> Key: JENA-1358
> URL: https://issues.apache.org/jira/browse/JENA-1358
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.3.0
>Reporter: Claude Warren
> Attachments: Example10.java
>
>
> the W3C SPARQL 1.1. update documentation contains an example numbered 10.
> https://www.w3.org/TR/sparql11-update/#example_10
> When executed in Jena the delete portion of that example is not executed.
> Example code to be attached



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (JENA-1358) UpdateRequest does not properly execute w3c update Example 10

[Claude Warren (JIRA)]

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

Claude Warren updated JENA-1358:

Attachment: Example10.java

Test code that executes the example 10 from the w3c SPARQL 1.1. documentation. 

> UpdateRequest does not properly execute w3c update Example 10
> -
>
> Key: JENA-1358
> URL: https://issues.apache.org/jira/browse/JENA-1358
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.3.0
>Reporter: Claude Warren
> Attachments: Example10.java
>
>
> the W3C SPARQL 1.1. update documentation contains an example numbered 10.
> https://www.w3.org/TR/sparql11-update/#example_10
> When executed in Jena the delete portion of that example is not executed.
> Example code to be attached



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (JENA-1358) UpdateRequest does not properly execute w3c update Example 10

[Claude Warren (JIRA)]

Claude Warren created JENA-1358:
---

 Summary: UpdateRequest does not properly execute w3c update 
Example 10
 Key: JENA-1358
 URL: https://issues.apache.org/jira/browse/JENA-1358
 Project: Apache Jena
  Issue Type: Bug
  Components: ARQ
Affects Versions: Jena 3.3.0
Reporter: Claude Warren


the W3C SPARQL 1.1. update documentation contains an example numbered 10.

https://www.w3.org/TR/sparql11-update/#example_10

When executed in Jena the delete portion of that example is not executed.

Example code to be attached



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (JENA-1352) QueryBuilder should provide UpdateBuilder

[Claude Warren (JIRA)]

Claude Warren created JENA-1352:
---

 Summary: QueryBuilder should provide UpdateBuilder
 Key: JENA-1352
 URL: https://issues.apache.org/jira/browse/JENA-1352
 Project: Apache Jena
  Issue Type: Improvement
  Components: QueryBuilder
Affects Versions: Jena 3.3.0
Reporter: Claude Warren
Assignee: Claude Warren
Priority: Minor


The QueryBuilder module should include an UpdateRequestBuilder that would apply 
the same sort of functionality to creating UpdateRequests.

The QueryBuilder framework will not work but should be extended to add support 
for UpdateRequest while providing the same Object based API style.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (JENA-1351) QueryBuilder does not support DescribeQuery

[Claude Warren (JIRA)]

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

Claude Warren resolved JENA-1351.
-
   Resolution: Fixed
Fix Version/s: Jena 3.4.0

added DescribeBuilder class and test code

> QueryBuilder does not support DescribeQuery
> ---
>
> Key: JENA-1351
> URL: https://issues.apache.org/jira/browse/JENA-1351
> Project: Apache Jena
>  Issue Type: Bug
>  Components: QueryBuilder
>Affects Versions: Jena 3.3.0
>Reporter: Claude Warren
>Assignee: Claude Warren
> Fix For: Jena 3.4.0
>
>
> QueryBuilder module does not have an option to produce Describe queries.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)