Re: RDFConnection
Just a thought on ergonomics: it might be nice to separate clear and delete, so instead of RDFConnection::delete either clearing or deleting a graph depending on whether it is the default graph, you have finer control and can clear a non-default graph. --- A. Soroka The University of Virginia Library On Aug 4, 2015, at 6:21 PM, Andy Seaborne a...@apache.org wrote: There's a note in the interface // Query // Maybe more query forms: querySelect(Query)? select(Query)? At the moment, the operations are the basic ones (the SPARQL protocols for query, update and GSP). There's scope to add forms on top. void execSelect(Query query, ConsumerQuerySolution action) is one possibility. Andy On 04/08/15 16:14, aj...@virginia.edu wrote: Is this a little bit like Sesame 4's new Repository helper type? Not totally the same thing, but similar in that it's bringing a lot of convenience together around the notion of dataset? http://rdf4j.org/doc/4/programming.docbook?view#Stream_based_querying_and_transaction_handling --- A. Soroka The University of Virginia Library On Aug 2, 2015, at 3:05 PM, Andy Seaborne a...@apache.org wrote: Stephen, all, Recently on users@ there was a question about the s-* in java. That got me thinking about an interface to pull together all SPARQL operations into one application-facing place. We have jena-jdbc, and jena-client already - this is my sketch take. [1] RDFConnection Currently, it's a sketch-for-discussion; it's a bit DatasetAccessor-like + SPARQL query + SPARQL Update. And some whole-dataset-REST-ish operations (that Fuseki happens to support). It's a chance to redo things a bit. RDFConnection uses the existing SPARQL+RDF classes and abstractions in ARQ, not strings, [*] rather than putting all app-visible clases in one package. Adding an equivalent of DatabaseClient to represent one place would be good - and add the admin operations, for Fuseki at least. Also, a streaming load possibility. Comments? Specific use cases? Andy (multi-operation transactions ... later!) [*] You can use strings as well - that's the way to get arbitrary non-standard extensions through. [1] https://github.com/afs/AFS-Dev/blob/master/src/main/java/projects/rdfconnection/RDFConnection.java
Re: Journaling DatasetGraph
Thanks for the feedback Andy.
2/
Datasets that provide support for MW cases and don't provide transactions
seem rather unlikely so may be document what kind of DatasetGraph is being
supported by DatasetGraphWithRecord then just use the underlying lock..
Okay, that's certainly simpler! And it keeps my grubby fingers out of Lock.
{grin}
3/
There are two thing to protect in DatasetGraphWithRecord : the underlying
dataset and transaction log for supporting abort for writers only. They can
have separate mechanisms. Use the dataset lock for the DatasetGraph actions
and make the transaction undo log operations be safe by other means.
You mean an independent lock visible only inside DatasetGraphWithRecord?
.. hmm ... the order of entries in the log may matter so true parallel MW
looks increasing hard to deal with anyway. Document and not worry for now?
My fear has been that MW means
a) a log per write-transaction and connections from the transaction to a
particular set of states for the indexes
b) with those forward states invisible outside the transaction
c) and all the nightmare fun of merging states!
---
A. Soroka
The University of Virginia Library
On Aug 4, 2015, at 4:32 PM, Andy Seaborne a...@apache.org wrote:
On 03/08/15 17:13, aj...@virginia.edu wrote:
I've made some emendations to (hopefully) fix this problem. In order to so
do, I added a method to Lock itself to report the quality of an instance,
simply as an enumeration. I had hoped to avoid touching any of the extant
code, but because Lock is a public type that can be instantiated by anyone,
I just can't see how to resolve this problem without some way for a Lock to
categorize itself independently of the type system's inheritance.
Feedback welcome!
A few things occur to me:
1/
The transaction log is for supporting abort for writers only. Nothing needs
to be done in DatasetGraphWithRecord for readers. DatasetGraphWithLock does
what's needed. So you don't even need to startRecording for a READ (and the
commit clear - _end always aborts is an interesting way to do it!).
2/
Datasets that provide support for MW cases and don't provide transactions
seem rather unlikely so may be document what kind of DatasetGraph is being
supported by DatasetGraphWithRecord then just use the underlying lock..
It's not just a case of using ConcurrentHashMap, say, as likely there would
be multiple of them for different indexes and that would give weird
consistency issues as different parts get updated safely with respect to part
of the datastructure but it will be visibly different depending on what the
reader uses. So I think MW will have additional coordination.
3/
There are two thing to protect in DatasetGraphWithRecord : the underlying
dataset and transaction log for supporting abort for writers only. They can
have separate mechanisms. Use the dataset lock for the DatasetGraph actions
and make the transaction undo log operations be safe by other means.
.. hmm ... the order of entries in the log may matter so true parallel MW
looks increasing hard to deal with anyway. Document and not worry for now?
Andy
---
A. Soroka
The University of Virginia Library
On Jul 29, 2015, at 5:04 PM, Andy Seaborne a...@apache.org wrote:
The lock provided by the underlying dataset may matter. DatasetGraphs
support critical sections. DatasetGraphWithLock uses critical sections of
the underlying dataset.
I gave an (hypothetical) example where the lock must be more restrictive
than ReentrantReadWriteLock (LockMRSW is a ReentrantReadWriteLock +
counting support to catch application errors).
DatasetGraphWithRecord is relying on single-W for its own datastructures.
Andy
On 29/07/15 21:22, aj...@virginia.edu wrote:
I'm not sure I understand this advice-- are you saying that because no
DatasetGraph can be assumed to support MR, there isn't any point in trying
to support MR at the level of DatasetGraphWithRecord? That would seem to
make my whole effort a bit pointless.
Or are you saying that because, in practice, all DatasetGraphs _do_
support MR, there's no need to enforce it at the level of
DatasetGraphWithRecord?
---
A. Soroka
The University of Virginia Library
On Jul 29, 2015, at 4:14 PM, Andy Seaborne a...@apache.org wrote:
On 27/07/15 18:06, aj...@virginia.edu wrote:
Is there some specific reason as to why you override the
DatasetGraphWithLock lock?
Yes, because DatasetGraphWithLock has no Lock that I could find, and it
inherits getLock() from DatasetGraphTrackActive, which just pulls the
lock from the wrapped DatasetGraph. I wanted to make sure that a MRSW
Lock is in play. But maybe I am misunderstanding the interaction here?
(No surprise! {grin})
A DatasetGraph provides whatever lock is suitable to meet the contract of
concurrency [1]
Some implementations (there aren't any) may not even be able to
Re: RDFConnection
The main complicating factor is that clear and delete are only separate operations if the storage layer stores graph names separately from graph data which the SPARQL specification specifically do not require For storage systems like TDB where only quads are stored the existence of a named graph is predicated by the existence of some quads in that graph and so delete is equivalent to clear because if you remove all quads for a graph TDB doesn't know about that graph any more The SPARQL specifications actually explicitly call this complication out in several places (search for empty graphs in the SPARQL 1.1 update spec) and various SPARQL Updates behaviours may differ depending on whether the storage layer records the presence of empty graphs or not Rob On 05/08/2015 13:44, aj...@virginia.edu aj...@virginia.edu wrote: Just a thought on ergonomics: it might be nice to separate clear and delete, so instead of RDFConnection::delete either clearing or deleting a graph depending on whether it is the default graph, you have finer control and can clear a non-default graph. --- A. Soroka The University of Virginia Library On Aug 4, 2015, at 6:21 PM, Andy Seaborne a...@apache.org wrote: There's a note in the interface // Query // Maybe more query forms: querySelect(Query)? select(Query)? At the moment, the operations are the basic ones (the SPARQL protocols for query, update and GSP). There's scope to add forms on top. void execSelect(Query query, ConsumerQuerySolution action) is one possibility. Andy On 04/08/15 16:14, aj...@virginia.edu wrote: Is this a little bit like Sesame 4's new Repository helper type? Not totally the same thing, but similar in that it's bringing a lot of convenience together around the notion of dataset? http://rdf4j.org/doc/4/programming.docbook?view#Stream_based_querying_an d_transaction_handling --- A. Soroka The University of Virginia Library On Aug 2, 2015, at 3:05 PM, Andy Seaborne a...@apache.org wrote: Stephen, all, Recently on users@ there was a question about the s-* in java. That got me thinking about an interface to pull together all SPARQL operations into one application-facing place. We have jena-jdbc, and jena-client already - this is my sketch take. [1] RDFConnection Currently, it's a sketch-for-discussion; it's a bit DatasetAccessor-like + SPARQL query + SPARQL Update. And some whole-dataset-REST-ish operations (that Fuseki happens to support). It's a chance to redo things a bit. RDFConnection uses the existing SPARQL+RDF classes and abstractions in ARQ, not strings, [*] rather than putting all app-visible clases in one package. Adding an equivalent of DatabaseClient to represent one place would be good - and add the admin operations, for Fuseki at least. Also, a streaming load possibility. Comments? Specific use cases? Andy (multi-operation transactions ... later!) [*] You can use strings as well - that's the way to get arbitrary non-standard extensions through. [1] https://github.com/afs/AFS-Dev/blob/master/src/main/java/projects/rdfco nnection/RDFConnection.java
Re: RDFConnection
Ah, that makes my distinction pretty meaningless! This abstraction seems meant to rub out just such differences. This does remind me of another potential nice small feature: a StreamTriple construct(Query query) method, maybe at first via QueryExecution::execConstructTriples. The AutoCloseable-ity of QueryExecution could pass through Stream's QueryExecution AutoCloseable-ity. With clever implementation eventually, some of the methods on Stream (e.g. filter) could get passed through to SPARQL execution. --- A. Soroka The University of Virginia Library On Aug 5, 2015, at 9:37 AM, Rob Vesse rve...@dotnetrdf.org wrote: The main complicating factor is that clear and delete are only separate operations if the storage layer stores graph names separately from graph data which the SPARQL specification specifically do not require For storage systems like TDB where only quads are stored the existence of a named graph is predicated by the existence of some quads in that graph and so delete is equivalent to clear because if you remove all quads for a graph TDB doesn't know about that graph any more The SPARQL specifications actually explicitly call this complication out in several places (search for empty graphs in the SPARQL 1.1 update spec) and various SPARQL Updates behaviours may differ depending on whether the storage layer records the presence of empty graphs or not Rob On 05/08/2015 13:44, aj...@virginia.edu aj...@virginia.edu wrote: Just a thought on ergonomics: it might be nice to separate clear and delete, so instead of RDFConnection::delete either clearing or deleting a graph depending on whether it is the default graph, you have finer control and can clear a non-default graph. --- A. Soroka The University of Virginia Library On Aug 4, 2015, at 6:21 PM, Andy Seaborne a...@apache.org wrote: There's a note in the interface // Query // Maybe more query forms: querySelect(Query)? select(Query)? At the moment, the operations are the basic ones (the SPARQL protocols for query, update and GSP). There's scope to add forms on top. void execSelect(Query query, ConsumerQuerySolution action) is one possibility. Andy On 04/08/15 16:14, aj...@virginia.edu wrote: Is this a little bit like Sesame 4's new Repository helper type? Not totally the same thing, but similar in that it's bringing a lot of convenience together around the notion of dataset? http://rdf4j.org/doc/4/programming.docbook?view#Stream_based_querying_an d_transaction_handling --- A. Soroka The University of Virginia Library On Aug 2, 2015, at 3:05 PM, Andy Seaborne a...@apache.org wrote: Stephen, all, Recently on users@ there was a question about the s-* in java. That got me thinking about an interface to pull together all SPARQL operations into one application-facing place. We have jena-jdbc, and jena-client already - this is my sketch take. [1] RDFConnection Currently, it's a sketch-for-discussion; it's a bit DatasetAccessor-like + SPARQL query + SPARQL Update. And some whole-dataset-REST-ish operations (that Fuseki happens to support). It's a chance to redo things a bit. RDFConnection uses the existing SPARQL+RDF classes and abstractions in ARQ, not strings, [*] rather than putting all app-visible clases in one package. Adding an equivalent of DatabaseClient to represent one place would be good - and add the admin operations, for Fuseki at least. Also, a streaming load possibility. Comments? Specific use cases? Andy (multi-operation transactions ... later!) [*] You can use strings as well - that's the way to get arbitrary non-standard extensions through. [1] https://github.com/afs/AFS-Dev/blob/master/src/main/java/projects/rdfco nnection/RDFConnection.java
Re: RDFConnection
On 04/08/15 22:26, Stephen Allen wrote:
To my knowledge, the only argument for using GSP instead of just
query+update would be performance/scalability. Although, when I have
encountered those issues, I've attempted to fix the problem in query+update
instead (i.e. adding streaming support for update). However, parsing large
SPARQL INSERT DATA operations is still slower than parsing NT (not to
mention rdf/thrift). There are potential solutions for that (a
sparql/thrift implementation, even if it only did INSERT/DELETE DATA as
binary and left queries as string blobs), but obviously that doesn't exist
yet.
...
One of the motivating features of jena-client was the ability to perform
large streaming updates (not just inserts/deletes) to a remote store. This
made up somewhat for the lack of remote transactions. But maybe that isn't
too great of an argument, when we could just go ahead and implement remote
transaction support (here is a proposal I haven't worked on in over a year
[3]).
GSP is very useful for managing data in a store when combined with a
union of named graphs as the default. Units of the overall graph can be
deleted (bnodes included) and replaced.
It's also useful when scripting management of the data : using curl/wget
you manage a store in simple scripts. Being able to do that in the same
way in Java is helpful so the user does not need two paradigms.
Fuseki2 provides streaming updates for upload by GSP. RDFConnection has
file upload features so the client-side does not need to parse the file,
just pass an InputStream to HTTP layer.
RDFConnection adds the natural REST ops on datasets.
Authentication: we should use the HttpOp code - one reason is that it
supports authentication for all HTTP verbs.
Jena-client's is more like JDBC
in that the transaction operations are exposed on the Connection object.
If the user chooses not to use the transaction mechanism then it will
default to using auto-commit
Agreed and in fact there an issue here with autocommit, streaming and
and SELECT queries. The ResultSet is passed out of the execSelect
operation but needs to be inside the transaction. Autocommit defeats that.
Which touches on the JDBC issue that drivers tend to execute and receive
all the results before the client can start working on the answers
(sometimes there are ways round this to be used with care). The issue
is badly behaved clients hogging resources in the server.
Some possibilities:
0/ Don't support autocommit. In the local case that is quite natural;
less so for the remote case because HTTP is not about state.
(I looked more at the remote case - e.g. the local connection
implementation isolates results to get the same semantics as remote.)
1/ Autocommit cases receive the results completely. Some idioms don't
work in autocommit more.
2/ An operation to make sure the QueryExecution is inside a transaction
and also closed.
RDFConnection
public default void querySelect(Query query,
ConsumerQuerySolution rowAction) {
Txn.executeRead(this, ()-{
try ( QueryExecution qExec = query(query) ) {
qExec.execSelect().forEachRemaining(rowAction);
}
} ) ;
}
By the way - I added explicit transaction support and some example usage.
Maybe we can use jena-client as a base to work from? If we feel we want to
add the separate GSP operations, then I think the extension point would be
to add a new GSP interface similar to Updater [5] (but lacking the generic
update query functionality).
I have no problem with jena-client as the starting point, I want to
understand its design first.
I'm not seeing what the separate interfaces and *Statement gives the
application - maybe I'm missing something here - it does seem to make it
more complicated compared to just performing the operation. For
*Statement, it's still limited in scope to the connection but can be
passed out.
Please remove the Sesame comments in javadoc and documentation. There's
no need to put comments about another community on implementation
choices that can change in javadoc and documentation. If you want to
write up the reasons then have a blog item somewhere, and hence making
it more time specific.
We might want to consider a non-HTTP remote connection; at least design
for the possibility. My motivation was initially more around working
with other people's published data (i.e. a long way away, not same data
centre).
Andy
[jira] [Created] (JENA-1006) How read and add triples to `Graph` at the same time?
Eugene Tenkaev created JENA-1006:
Summary: How read and add triples to `Graph` at the same time?
Key: JENA-1006
URL: https://issues.apache.org/jira/browse/JENA-1006
Project: Apache Jena
Issue Type: Question
Components: Core, TDB
Affects Versions: Jena 2.13.0
Reporter: Eugene Tenkaev
Here is my code:
{code:java}
public class App {
public static void main(String[] args) {
DatasetGraph datasetGraph = TDBFactory.createDatasetGraph();
Graph graph = datasetGraph.getDefaultGraph();
// Fill graph.
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(name),
NodeFactory.createLiteral(Unit 13, en)
)
);
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(type),
NodeFactory.createURI(robot)
)
);
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(creationYear),
NodeFactory.createURI(2015)
)
);
// Test
ExtendedIteratorTriple iter = graph.find(
Node.ANY,
NodeFactory.createURI(creationYear),
NodeFactory.createURI(2015)
);
while (iter.hasNext()) {
Triple triple = iter.next();
Node subject = triple.getSubject();
// Exception here.
graph.add(
new Triple(
subject, NodeFactory.createURI(status),
NodeFactory.createURI(available)
)
);
}
}
}
{code}
This code gives me exception:
{noformat}
Exception in thread main java.util.ConcurrentModificationException: Iterator:
started at 8, now 9
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.policyError(DatasetControlMRSW.java:157)
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.access$000(DatasetControlMRSW.java:32)
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW$IteratorCheckNotConcurrent.checkCourrentModification(DatasetControlMRSW.java:110)
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW$IteratorCheckNotConcurrent.hasNext(DatasetControlMRSW.java:118)
at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318)
at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318)
at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318)
at org.apache.jena.atlas.iterator.Iter.hasNext(Iter.java:942)
at
com.hp.hpl.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90)
at com.github.hronom.test.jena.App.main(App.java:48)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
{noformat}
I accept this.
But how I must change code, to add meta info {{status available}} to every
{{www.test.org/unit13}} that has {{creationYear 2015}}?
Test project on [GitHub|https://github.com/Hronom/test-jena]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JENA-1006) How read and add triples to `Graph` at the same time?
[
https://issues.apache.org/jira/browse/JENA-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eugene Tenkaev updated JENA-1006:
-
Description:
Here is my code:
{code:java}
public class App {
public static void main(String[] args) {
DatasetGraph datasetGraph = TDBFactory.createDatasetGraph();
Graph graph = datasetGraph.getDefaultGraph();
// Fill graph.
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(name),
NodeFactory.createLiteral(Unit 13, en)
)
);
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(type),
NodeFactory.createURI(robot)
)
);
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(creationYear),
NodeFactory.createURI(2015)
)
);
// Test
ExtendedIteratorTriple iter = graph.find(
Node.ANY,
NodeFactory.createURI(creationYear),
NodeFactory.createURI(2015)
);
while (iter.hasNext()) {
Triple triple = iter.next();
Node subject = triple.getSubject();
// Exception here.
graph.add(
new Triple(
subject, NodeFactory.createURI(status),
NodeFactory.createURI(available)
)
);
}
}
}
{code}
This code gives me exception:
{noformat}
Exception in thread main java.util.ConcurrentModificationException: Iterator:
started at 8, now 9
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.policyError(DatasetControlMRSW.java:157)
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.access$000(DatasetControlMRSW.java:32)
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW$IteratorCheckNotConcurrent.checkCourrentModification(DatasetControlMRSW.java:110)
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW$IteratorCheckNotConcurrent.hasNext(DatasetControlMRSW.java:118)
at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318)
at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318)
at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318)
at org.apache.jena.atlas.iterator.Iter.hasNext(Iter.java:942)
at
com.hp.hpl.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90)
at com.github.hronom.test.jena.App.main(App.java:48)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
{noformat}
I accept this.
But how I must change code, to add meta info {{status available}} to every
{{www.test.org/unit13}} that has {{creationYear 2015}}?
Test project on [GitHub|https://github.com/Hronom/test-jena]
Please help me:P
was:
Here is my code:
{code:java}
public class App {
public static void main(String[] args) {
DatasetGraph datasetGraph = TDBFactory.createDatasetGraph();
Graph graph = datasetGraph.getDefaultGraph();
// Fill graph.
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(name),
NodeFactory.createLiteral(Unit 13, en)
)
);
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(type),
NodeFactory.createURI(robot)
)
);
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(creationYear),
NodeFactory.createURI(2015)
)
);
// Test
ExtendedIteratorTriple iter = graph.find(
Node.ANY,
NodeFactory.createURI(creationYear),
NodeFactory.createURI(2015)
);
while (iter.hasNext()) {
Triple triple = iter.next();
Node subject = triple.getSubject();
// Exception here.
graph.add(
new Triple(
subject, NodeFactory.createURI(status),
NodeFactory.createURI(available)
)
);
}
}
}
{code}
This code gives me exception:
{noformat}
Exception in thread main java.util.ConcurrentModificationException: Iterator:
started at 8, now 9
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.policyError(DatasetControlMRSW.java:157)
at
[jira] [Commented] (JENA-1006) How read and add triples to `Graph` at the same time?
[
https://issues.apache.org/jira/browse/JENA-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14658801#comment-14658801
]
Andy Seaborne commented on JENA-1006:
-
Iterators read from the database when {{hasNext}}/{{next}} are called. As with
Java iterators on collections, if the storage changes, the iterator is
inconsistent. TDB happens to explicitly check.
You need to complete the iterator, keeping the triples returned. e.g.
{{ExtendedIterator.toList()}}
Sketch:
{noformat}
IteratorTriple iter = graph.find(...).toList().iterator() ;
{noformat}
or
{noformat}
for ( Triple t : graph.find(...).toList() ) {
...
}
{noformat}
Consider using transactions.
Consider using SPARQL Update.
Use absolute URIs.
How read and add triples to `Graph` at the same time?
-
Key: JENA-1006
URL: https://issues.apache.org/jira/browse/JENA-1006
Project: Apache Jena
Issue Type: Question
Components: Core, TDB
Affects Versions: Jena 2.13.0
Reporter: Eugene Tenkaev
Here is my code:
{code:java}
public class App {
public static void main(String[] args) {
DatasetGraph datasetGraph = TDBFactory.createDatasetGraph();
Graph graph = datasetGraph.getDefaultGraph();
// Fill graph.
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(name),
NodeFactory.createLiteral(Unit 13, en)
)
);
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(type),
NodeFactory.createURI(robot)
)
);
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(creationYear),
NodeFactory.createURI(2015)
)
);
// Test
ExtendedIteratorTriple iter = graph.find(
Node.ANY,
NodeFactory.createURI(creationYear),
NodeFactory.createURI(2015)
);
while (iter.hasNext()) {
Triple triple = iter.next();
Node subject = triple.getSubject();
// Exception here.
graph.add(
new Triple(
subject, NodeFactory.createURI(status),
NodeFactory.createURI(available)
)
);
}
}
}
{code}
This code gives me exception:
{noformat}
Exception in thread main java.util.ConcurrentModificationException:
Iterator: started at 8, now 9
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.policyError(DatasetControlMRSW.java:157)
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.access$000(DatasetControlMRSW.java:32)
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW$IteratorCheckNotConcurrent.checkCourrentModification(DatasetControlMRSW.java:110)
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW$IteratorCheckNotConcurrent.hasNext(DatasetControlMRSW.java:118)
at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318)
at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318)
at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318)
at org.apache.jena.atlas.iterator.Iter.hasNext(Iter.java:942)
at
com.hp.hpl.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90)
at com.github.hronom.test.jena.App.main(App.java:48)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
{noformat}
I accept this.
But how I must change code, to add meta info {{status available}} to
every {{www.test.org/unit13}} that has {{creationYear 2015}}?
Test project on [GitHub|https://github.com/Hronom/test-jena]
Please help me:P
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JENA-1006) How read and add triples to `Graph` at the same time?
[
https://issues.apache.org/jira/browse/JENA-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Seaborne updated JENA-1006:
Priority: Minor (was: Major)
How read and add triples to `Graph` at the same time?
-
Key: JENA-1006
URL: https://issues.apache.org/jira/browse/JENA-1006
Project: Apache Jena
Issue Type: Question
Components: Core, TDB
Affects Versions: Jena 2.13.0
Reporter: Eugene Tenkaev
Priority: Minor
Here is my code:
{code:java}
public class App {
public static void main(String[] args) {
DatasetGraph datasetGraph = TDBFactory.createDatasetGraph();
Graph graph = datasetGraph.getDefaultGraph();
// Fill graph.
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(name),
NodeFactory.createLiteral(Unit 13, en)
)
);
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(type),
NodeFactory.createURI(robot)
)
);
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(creationYear),
NodeFactory.createURI(2015)
)
);
// Test
ExtendedIteratorTriple iter = graph.find(
Node.ANY,
NodeFactory.createURI(creationYear),
NodeFactory.createURI(2015)
);
while (iter.hasNext()) {
Triple triple = iter.next();
Node subject = triple.getSubject();
// Exception here.
graph.add(
new Triple(
subject, NodeFactory.createURI(status),
NodeFactory.createURI(available)
)
);
}
}
}
{code}
This code gives me exception:
{noformat}
Exception in thread main java.util.ConcurrentModificationException:
Iterator: started at 8, now 9
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.policyError(DatasetControlMRSW.java:157)
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.access$000(DatasetControlMRSW.java:32)
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW$IteratorCheckNotConcurrent.checkCourrentModification(DatasetControlMRSW.java:110)
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW$IteratorCheckNotConcurrent.hasNext(DatasetControlMRSW.java:118)
at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318)
at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318)
at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318)
at org.apache.jena.atlas.iterator.Iter.hasNext(Iter.java:942)
at
com.hp.hpl.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90)
at com.github.hronom.test.jena.App.main(App.java:48)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
{noformat}
I accept this.
But how I must change code, to add meta info {{status available}} to
every {{www.test.org/unit13}} that has {{creationYear 2015}}?
Test project on [GitHub|https://github.com/Hronom/test-jena]
Please help me:P
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JENA-1006) How read and add triples to `Graph` at the same time?
[
https://issues.apache.org/jira/browse/JENA-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14658805#comment-14658805
]
Andy Seaborne commented on JENA-1006:
-
Questions usually go to us...@jena.apahe.org.
http://jena.apache.org/help_and_support/index.html
How read and add triples to `Graph` at the same time?
-
Key: JENA-1006
URL: https://issues.apache.org/jira/browse/JENA-1006
Project: Apache Jena
Issue Type: Question
Components: Core, TDB
Affects Versions: Jena 2.13.0
Reporter: Eugene Tenkaev
Priority: Minor
Here is my code:
{code:java}
public class App {
public static void main(String[] args) {
DatasetGraph datasetGraph = TDBFactory.createDatasetGraph();
Graph graph = datasetGraph.getDefaultGraph();
// Fill graph.
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(name),
NodeFactory.createLiteral(Unit 13, en)
)
);
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(type),
NodeFactory.createURI(robot)
)
);
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(creationYear),
NodeFactory.createURI(2015)
)
);
// Test
ExtendedIteratorTriple iter = graph.find(
Node.ANY,
NodeFactory.createURI(creationYear),
NodeFactory.createURI(2015)
);
while (iter.hasNext()) {
Triple triple = iter.next();
Node subject = triple.getSubject();
// Exception here.
graph.add(
new Triple(
subject, NodeFactory.createURI(status),
NodeFactory.createURI(available)
)
);
}
}
}
{code}
This code gives me exception:
{noformat}
Exception in thread main java.util.ConcurrentModificationException:
Iterator: started at 8, now 9
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.policyError(DatasetControlMRSW.java:157)
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.access$000(DatasetControlMRSW.java:32)
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW$IteratorCheckNotConcurrent.checkCourrentModification(DatasetControlMRSW.java:110)
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW$IteratorCheckNotConcurrent.hasNext(DatasetControlMRSW.java:118)
at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318)
at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318)
at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318)
at org.apache.jena.atlas.iterator.Iter.hasNext(Iter.java:942)
at
com.hp.hpl.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90)
at com.github.hronom.test.jena.App.main(App.java:48)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
{noformat}
I accept this.
But how I must change code, to add meta info {{status available}} to
every {{www.test.org/unit13}} that has {{creationYear 2015}}?
Test project on [GitHub|https://github.com/Hronom/test-jena]
Please help me:P
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JENA-1006) How read and add triples to `Graph` at the same time?
[
https://issues.apache.org/jira/browse/JENA-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14658864#comment-14658864
]
Andy Seaborne commented on JENA-1006:
-
https://jena.apache.org/documentation/tdb/tdb_transactions.html
How read and add triples to `Graph` at the same time?
-
Key: JENA-1006
URL: https://issues.apache.org/jira/browse/JENA-1006
Project: Apache Jena
Issue Type: Question
Components: Core, TDB
Affects Versions: Jena 2.13.0
Reporter: Eugene Tenkaev
Priority: Minor
Here is my code:
{code:java}
public class App {
public static void main(String[] args) {
DatasetGraph datasetGraph = TDBFactory.createDatasetGraph();
Graph graph = datasetGraph.getDefaultGraph();
// Fill graph.
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(name),
NodeFactory.createLiteral(Unit 13, en)
)
);
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(type),
NodeFactory.createURI(robot)
)
);
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(creationYear),
NodeFactory.createURI(2015)
)
);
// Test
ExtendedIteratorTriple iter = graph.find(
Node.ANY,
NodeFactory.createURI(creationYear),
NodeFactory.createURI(2015)
);
while (iter.hasNext()) {
Triple triple = iter.next();
Node subject = triple.getSubject();
// Exception here.
graph.add(
new Triple(
subject, NodeFactory.createURI(status),
NodeFactory.createURI(available)
)
);
}
}
}
{code}
This code gives me exception:
{noformat}
Exception in thread main java.util.ConcurrentModificationException:
Iterator: started at 8, now 9
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.policyError(DatasetControlMRSW.java:157)
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.access$000(DatasetControlMRSW.java:32)
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW$IteratorCheckNotConcurrent.checkCourrentModification(DatasetControlMRSW.java:110)
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW$IteratorCheckNotConcurrent.hasNext(DatasetControlMRSW.java:118)
at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318)
at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318)
at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318)
at org.apache.jena.atlas.iterator.Iter.hasNext(Iter.java:942)
at
com.hp.hpl.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90)
at com.github.hronom.test.jena.App.main(App.java:48)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
{noformat}
I accept this.
But how I must change code, to add meta info {{status available}} to
every {{www.test.org/unit13}} that has {{creationYear 2015}}?
Test project on [GitHub|https://github.com/Hronom/test-jena]
Please help me:P
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (JENA-1006) How read and add triples to `Graph` at the same time?
[
https://issues.apache.org/jira/browse/JENA-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Seaborne closed JENA-1006.
---
How read and add triples to `Graph` at the same time?
-
Key: JENA-1006
URL: https://issues.apache.org/jira/browse/JENA-1006
Project: Apache Jena
Issue Type: Question
Components: Core, TDB
Affects Versions: Jena 2.13.0
Reporter: Eugene Tenkaev
Priority: Minor
Fix For: Jena 3.0.1
Here is my code:
{code:java}
public class App {
public static void main(String[] args) {
DatasetGraph datasetGraph = TDBFactory.createDatasetGraph();
Graph graph = datasetGraph.getDefaultGraph();
// Fill graph.
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(name),
NodeFactory.createLiteral(Unit 13, en)
)
);
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(type),
NodeFactory.createURI(robot)
)
);
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(creationYear),
NodeFactory.createURI(2015)
)
);
// Test
ExtendedIteratorTriple iter = graph.find(
Node.ANY,
NodeFactory.createURI(creationYear),
NodeFactory.createURI(2015)
);
while (iter.hasNext()) {
Triple triple = iter.next();
Node subject = triple.getSubject();
// Exception here.
graph.add(
new Triple(
subject, NodeFactory.createURI(status),
NodeFactory.createURI(available)
)
);
}
}
}
{code}
This code gives me exception:
{noformat}
Exception in thread main java.util.ConcurrentModificationException:
Iterator: started at 8, now 9
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.policyError(DatasetControlMRSW.java:157)
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.access$000(DatasetControlMRSW.java:32)
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW$IteratorCheckNotConcurrent.checkCourrentModification(DatasetControlMRSW.java:110)
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW$IteratorCheckNotConcurrent.hasNext(DatasetControlMRSW.java:118)
at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318)
at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318)
at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318)
at org.apache.jena.atlas.iterator.Iter.hasNext(Iter.java:942)
at
com.hp.hpl.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90)
at com.github.hronom.test.jena.App.main(App.java:48)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
{noformat}
I accept this.
But how I must change code, to add meta info {{status available}} to
every {{www.test.org/unit13}} that has {{creationYear 2015}}?
Test project on [GitHub|https://github.com/Hronom/test-jena]
Please help me:P
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (JENA-1006) How read and add triples to `Graph` at the same time?
[
https://issues.apache.org/jira/browse/JENA-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Seaborne resolved JENA-1006.
-
Resolution: Done
Fix Version/s: Jena 3.0.1
How read and add triples to `Graph` at the same time?
-
Key: JENA-1006
URL: https://issues.apache.org/jira/browse/JENA-1006
Project: Apache Jena
Issue Type: Question
Components: Core, TDB
Affects Versions: Jena 2.13.0
Reporter: Eugene Tenkaev
Priority: Minor
Fix For: Jena 3.0.1
Here is my code:
{code:java}
public class App {
public static void main(String[] args) {
DatasetGraph datasetGraph = TDBFactory.createDatasetGraph();
Graph graph = datasetGraph.getDefaultGraph();
// Fill graph.
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(name),
NodeFactory.createLiteral(Unit 13, en)
)
);
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(type),
NodeFactory.createURI(robot)
)
);
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(creationYear),
NodeFactory.createURI(2015)
)
);
// Test
ExtendedIteratorTriple iter = graph.find(
Node.ANY,
NodeFactory.createURI(creationYear),
NodeFactory.createURI(2015)
);
while (iter.hasNext()) {
Triple triple = iter.next();
Node subject = triple.getSubject();
// Exception here.
graph.add(
new Triple(
subject, NodeFactory.createURI(status),
NodeFactory.createURI(available)
)
);
}
}
}
{code}
This code gives me exception:
{noformat}
Exception in thread main java.util.ConcurrentModificationException:
Iterator: started at 8, now 9
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.policyError(DatasetControlMRSW.java:157)
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.access$000(DatasetControlMRSW.java:32)
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW$IteratorCheckNotConcurrent.checkCourrentModification(DatasetControlMRSW.java:110)
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW$IteratorCheckNotConcurrent.hasNext(DatasetControlMRSW.java:118)
at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318)
at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318)
at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318)
at org.apache.jena.atlas.iterator.Iter.hasNext(Iter.java:942)
at
com.hp.hpl.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90)
at com.github.hronom.test.jena.App.main(App.java:48)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
{noformat}
I accept this.
But how I must change code, to add meta info {{status available}} to
every {{www.test.org/unit13}} that has {{creationYear 2015}}?
Test project on [GitHub|https://github.com/Hronom/test-jena]
Please help me:P
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JENA-1006) How read and add triples to `Graph` at the same time?
[
https://issues.apache.org/jira/browse/JENA-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14658912#comment-14658912
]
Eugene Tenkaev commented on JENA-1006:
--
Yes I read that, but how I can get from {{DatasetGraph}} or {{Graph}} the
{{Dataset}}?
Is this
{{code:java}}
Dataset dataset = TDBFactory.createDataset();
DatasetGraph datasetGraph = dataset.asDatasetGraph();
Graph graph = datasetGraph.getDefaultGraph();
{{code}}
a good solution? Is {{dataset.asDatasetGraph()}} has a bad side?
How read and add triples to `Graph` at the same time?
-
Key: JENA-1006
URL: https://issues.apache.org/jira/browse/JENA-1006
Project: Apache Jena
Issue Type: Question
Components: Core, TDB
Affects Versions: Jena 2.13.0
Reporter: Eugene Tenkaev
Priority: Minor
Fix For: Jena 3.0.1
Here is my code:
{code:java}
public class App {
public static void main(String[] args) {
DatasetGraph datasetGraph = TDBFactory.createDatasetGraph();
Graph graph = datasetGraph.getDefaultGraph();
// Fill graph.
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(name),
NodeFactory.createLiteral(Unit 13, en)
)
);
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(type),
NodeFactory.createURI(robot)
)
);
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(creationYear),
NodeFactory.createURI(2015)
)
);
// Test
ExtendedIteratorTriple iter = graph.find(
Node.ANY,
NodeFactory.createURI(creationYear),
NodeFactory.createURI(2015)
);
while (iter.hasNext()) {
Triple triple = iter.next();
Node subject = triple.getSubject();
// Exception here.
graph.add(
new Triple(
subject, NodeFactory.createURI(status),
NodeFactory.createURI(available)
)
);
}
}
}
{code}
This code gives me exception:
{noformat}
Exception in thread main java.util.ConcurrentModificationException:
Iterator: started at 8, now 9
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.policyError(DatasetControlMRSW.java:157)
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.access$000(DatasetControlMRSW.java:32)
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW$IteratorCheckNotConcurrent.checkCourrentModification(DatasetControlMRSW.java:110)
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW$IteratorCheckNotConcurrent.hasNext(DatasetControlMRSW.java:118)
at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318)
at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318)
at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318)
at org.apache.jena.atlas.iterator.Iter.hasNext(Iter.java:942)
at
com.hp.hpl.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90)
at com.github.hronom.test.jena.App.main(App.java:48)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
{noformat}
I accept this.
But how I must change code, to add meta info {{status available}} to
every {{www.test.org/unit13}} that has {{creationYear 2015}}?
Test project on [GitHub|https://github.com/Hronom/test-jena]
Please help me:P
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (JENA-1006) How read and add triples to `Graph` at the same time?
[
https://issues.apache.org/jira/browse/JENA-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14658912#comment-14658912
]
Eugene Tenkaev edited comment on JENA-1006 at 8/5/15 9:04 PM:
--
Yes I read that, but how I can get from {{DatasetGraph}} or {{Graph}} the
{{Dataset}}?
Is this
{code:java}
Dataset dataset = TDBFactory.createDataset();
DatasetGraph datasetGraph = dataset.asDatasetGraph();
Graph graph = datasetGraph.getDefaultGraph();
{code}
a good solution? Is {{dataset.asDatasetGraph()}} has a bad side?
was (Author: hronom):
Yes I read that, but how I can get from {{DatasetGraph}} or {{Graph}} the
{{Dataset}}?
Is this
{{code:java}}
Dataset dataset = TDBFactory.createDataset();
DatasetGraph datasetGraph = dataset.asDatasetGraph();
Graph graph = datasetGraph.getDefaultGraph();
{{code}}
a good solution? Is {{dataset.asDatasetGraph()}} has a bad side?
How read and add triples to `Graph` at the same time?
-
Key: JENA-1006
URL: https://issues.apache.org/jira/browse/JENA-1006
Project: Apache Jena
Issue Type: Question
Components: Core, TDB
Affects Versions: Jena 2.13.0
Reporter: Eugene Tenkaev
Priority: Minor
Fix For: Jena 3.0.1
Here is my code:
{code:java}
public class App {
public static void main(String[] args) {
DatasetGraph datasetGraph = TDBFactory.createDatasetGraph();
Graph graph = datasetGraph.getDefaultGraph();
// Fill graph.
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(name),
NodeFactory.createLiteral(Unit 13, en)
)
);
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(type),
NodeFactory.createURI(robot)
)
);
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(creationYear),
NodeFactory.createURI(2015)
)
);
// Test
ExtendedIteratorTriple iter = graph.find(
Node.ANY,
NodeFactory.createURI(creationYear),
NodeFactory.createURI(2015)
);
while (iter.hasNext()) {
Triple triple = iter.next();
Node subject = triple.getSubject();
// Exception here.
graph.add(
new Triple(
subject, NodeFactory.createURI(status),
NodeFactory.createURI(available)
)
);
}
}
}
{code}
This code gives me exception:
{noformat}
Exception in thread main java.util.ConcurrentModificationException:
Iterator: started at 8, now 9
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.policyError(DatasetControlMRSW.java:157)
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.access$000(DatasetControlMRSW.java:32)
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW$IteratorCheckNotConcurrent.checkCourrentModification(DatasetControlMRSW.java:110)
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW$IteratorCheckNotConcurrent.hasNext(DatasetControlMRSW.java:118)
at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318)
at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318)
at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318)
at org.apache.jena.atlas.iterator.Iter.hasNext(Iter.java:942)
at
com.hp.hpl.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90)
at com.github.hronom.test.jena.App.main(App.java:48)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
{noformat}
I accept this.
But how I must change code, to add meta info {{status available}} to
every {{www.test.org/unit13}} that has {{creationYear 2015}}?
Test project on [GitHub|https://github.com/Hronom/test-jena]
Please help me:P
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (JENA-1006) How read and add triples to `Graph` at the same time?
[
https://issues.apache.org/jira/browse/JENA-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eugene Tenkaev reopened JENA-1006:
--
How read and add triples to `Graph` at the same time?
-
Key: JENA-1006
URL: https://issues.apache.org/jira/browse/JENA-1006
Project: Apache Jena
Issue Type: Question
Components: Core, TDB
Affects Versions: Jena 2.13.0
Reporter: Eugene Tenkaev
Priority: Minor
Fix For: Jena 3.0.1
Here is my code:
{code:java}
public class App {
public static void main(String[] args) {
DatasetGraph datasetGraph = TDBFactory.createDatasetGraph();
Graph graph = datasetGraph.getDefaultGraph();
// Fill graph.
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(name),
NodeFactory.createLiteral(Unit 13, en)
)
);
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(type),
NodeFactory.createURI(robot)
)
);
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(creationYear),
NodeFactory.createURI(2015)
)
);
// Test
ExtendedIteratorTriple iter = graph.find(
Node.ANY,
NodeFactory.createURI(creationYear),
NodeFactory.createURI(2015)
);
while (iter.hasNext()) {
Triple triple = iter.next();
Node subject = triple.getSubject();
// Exception here.
graph.add(
new Triple(
subject, NodeFactory.createURI(status),
NodeFactory.createURI(available)
)
);
}
}
}
{code}
This code gives me exception:
{noformat}
Exception in thread main java.util.ConcurrentModificationException:
Iterator: started at 8, now 9
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.policyError(DatasetControlMRSW.java:157)
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.access$000(DatasetControlMRSW.java:32)
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW$IteratorCheckNotConcurrent.checkCourrentModification(DatasetControlMRSW.java:110)
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW$IteratorCheckNotConcurrent.hasNext(DatasetControlMRSW.java:118)
at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318)
at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318)
at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318)
at org.apache.jena.atlas.iterator.Iter.hasNext(Iter.java:942)
at
com.hp.hpl.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90)
at com.github.hronom.test.jena.App.main(App.java:48)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
{noformat}
I accept this.
But how I must change code, to add meta info {{status available}} to
every {{www.test.org/unit13}} that has {{creationYear 2015}}?
Test project on [GitHub|https://github.com/Hronom/test-jena]
Please help me:P
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (JENA-1006) How read and add triples to `Graph` at the same time?
[
https://issues.apache.org/jira/browse/JENA-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14658912#comment-14658912
]
Eugene Tenkaev edited comment on JENA-1006 at 8/5/15 9:15 PM:
--
Yes I read that, but how I can get from {{DatasetGraph}} or {{Graph}} the
{{Dataset}}?
Is this
{code:java}
Dataset dataset = TDBFactory.createDataset();
DatasetGraph datasetGraph = dataset.asDatasetGraph();
Graph graph = datasetGraph.getDefaultGraph();
{code}
a good solution? Is {{dataset.asDatasetGraph()}} has a bad side?
Or maybe this:
{code:java}
DatasetGraph datasetGraph = TDBFactory.createDatasetGraph();
Graph graph = datasetGraph.getDefaultGraph();
Dataset dataset = DatasetImpl.wrap(datasetGraph);
{code}
{{DatasetImpl.wrap}} good solution?
was (Author: hronom):
Yes I read that, but how I can get from {{DatasetGraph}} or {{Graph}} the
{{Dataset}}?
Is this
{code:java}
Dataset dataset = TDBFactory.createDataset();
DatasetGraph datasetGraph = dataset.asDatasetGraph();
Graph graph = datasetGraph.getDefaultGraph();
{code}
a good solution? Is {{dataset.asDatasetGraph()}} has a bad side?
How read and add triples to `Graph` at the same time?
-
Key: JENA-1006
URL: https://issues.apache.org/jira/browse/JENA-1006
Project: Apache Jena
Issue Type: Question
Components: Core, TDB
Affects Versions: Jena 2.13.0
Reporter: Eugene Tenkaev
Priority: Minor
Fix For: Jena 3.0.1
Here is my code:
{code:java}
public class App {
public static void main(String[] args) {
DatasetGraph datasetGraph = TDBFactory.createDatasetGraph();
Graph graph = datasetGraph.getDefaultGraph();
// Fill graph.
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(name),
NodeFactory.createLiteral(Unit 13, en)
)
);
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(type),
NodeFactory.createURI(robot)
)
);
graph.add(
new Triple(
NodeFactory.createURI(www.test.org/unit13),
NodeFactory.createURI(creationYear),
NodeFactory.createURI(2015)
)
);
// Test
ExtendedIteratorTriple iter = graph.find(
Node.ANY,
NodeFactory.createURI(creationYear),
NodeFactory.createURI(2015)
);
while (iter.hasNext()) {
Triple triple = iter.next();
Node subject = triple.getSubject();
// Exception here.
graph.add(
new Triple(
subject, NodeFactory.createURI(status),
NodeFactory.createURI(available)
)
);
}
}
}
{code}
This code gives me exception:
{noformat}
Exception in thread main java.util.ConcurrentModificationException:
Iterator: started at 8, now 9
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.policyError(DatasetControlMRSW.java:157)
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.access$000(DatasetControlMRSW.java:32)
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW$IteratorCheckNotConcurrent.checkCourrentModification(DatasetControlMRSW.java:110)
at
com.hp.hpl.jena.tdb.sys.DatasetControlMRSW$IteratorCheckNotConcurrent.hasNext(DatasetControlMRSW.java:118)
at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318)
at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318)
at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318)
at org.apache.jena.atlas.iterator.Iter.hasNext(Iter.java:942)
at
com.hp.hpl.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90)
at com.github.hronom.test.jena.App.main(App.java:48)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
{noformat}
I accept this.
But how I must change code, to add meta info {{status available}} to
every {{www.test.org/unit13}} that has {{creationYear 2015}}?
Test project on [GitHub|https://github.com/Hronom/test-jena]
Please help me:P
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Fwd: Final Deliveries of GSoC Project (JENA-491)
Hi,
I've fixed the bugs related to syntax checks. Please see my latest
commits. Here're the output of the syntax files through qparse (you
can also run ExampleConstructQuads.java to get the results). Are
these with the expected behaviors, especially for
syntax-quad-construct-07.arq?
run-construct-quad-test:
File: syntax-quad-construct-01.arq
PREFIX : http://example/
CONSTRUCT { GRAPH :g { :s :p :o } } WHERE {}
Output of qparse --file syntax-quad-construct-01.arq
PREFIX : http://example/
CONSTRUCT
{
GRAPH :g
{ :s :p :o .}
}
WHERE
{ }
File: syntax-quad-construct-02.arq
PREFIX : http://example/
CONSTRUCT { GRAPH ?g { ?s ?p ?o } } WHERE { ?s ?p ?o }
Output of qparse --file syntax-quad-construct-02.arq
PREFIX : http://example/
CONSTRUCT
{
GRAPH ?g
{ ?s ?p ?o .}
}
WHERE
{ ?s ?p ?o }
File: syntax-quad-construct-03.arq
PREFIX : http://example/
CONSTRUCT { :s :p :o } WHERE {}
Output of qparse --file syntax-quad-construct-03.arq
PREFIX : http://example/
CONSTRUCT
{
:s :p :o .
}
WHERE
{ }
File: syntax-quad-construct-04.arq
PREFIX : http://example/
CONSTRUCT {
GRAPH ?g { :s :p :o }
?s ?p ?o
}
WHERE
{ GRAPH ?g { ?s ?p ?o } }
Output of qparse --file syntax-quad-construct-04.arq
PREFIX : http://example/
CONSTRUCT
{
GRAPH ?g
{ :s :p :o .}
?s ?p ?o .
}
WHERE
{ GRAPH ?g
{ ?s ?p ?o }
}
File: syntax-quad-construct-05.arq
PREFIX : http://example/
CONSTRUCT {
?s ?p ?o
GRAPH ?g { :s :p :o }
}
WHERE
{ GRAPH ?g { ?s ?p ?o } }
Output of qparse --file syntax-quad-construct-05.arq
PREFIX : http://example/
CONSTRUCT
{
?s ?p ?o .
GRAPH ?g
{ :s :p :o .}
}
WHERE
{ GRAPH ?g
{ ?s ?p ?o }
}
File: syntax-quad-construct-06.arq
PREFIX : http://example/
CONSTRUCT {
GRAPH ?g { :s :p :o }
?s ?p ?o .
?s ?p ?o .
GRAPH ?g { ?s ?p ?o }
?s ?p ?o .
?s ?p ?o
GRAPH ?g { ?s ?p ?o }
}
WHERE
{ GRAPH ?g { ?s ?p ?o } }
Output of qparse --file syntax-quad-construct-06.arq
PREFIX : http://example/
CONSTRUCT
{
GRAPH ?g
{ :s :p :o .}
?s ?p ?o .
?s ?p ?o .
GRAPH ?g
{ ?s ?p ?o .}
?s ?p ?o .
?s ?p ?o .
GRAPH ?g
{ ?s ?p ?o .}
}
WHERE
{ GRAPH ?g
{ ?s ?p ?o }
}
File: syntax-quad-construct-07.arq
PREFIX : http://example/
CONSTRUCT {
GRAPH urn:x-arq:DefaultGraphNode {:s :p :o .}
}
WHERE {}
Output of qparse --file syntax-quad-construct-07.arq
PREFIX : http://example/
CONSTRUCT
{
:s :p :o .
}
WHERE
{ }
File: syntax-quad-construct-08.arq
PREFIX : http://example/
CONSTRUCT {
GRAPH ?g { :s :p :o }
GRAPH ?g1 { :s :p :o }
}
WHERE
{ }
Output of qparse --file syntax-quad-construct-08.arq
PREFIX : http://example/
CONSTRUCT
{
GRAPH ?g
{ :s :p :o .}
GRAPH ?g1
{ :s :p :o .}
}
WHERE
{ }
On Sun, Aug 2, 2015 at 9:14 AM, Ying Jiang jpz6311...@gmail.com wrote:
Hi Qihong,
I re-checked the code you commited. Most of the hashCode issues for
arq.qparse that Andy pointed out are due to the incorrect
serialization of the Template. The code can only deal with the quads
with the same graph node, for which it may not always be the case in
practcial terms. Please make sure each example syntax file can pass
the checking process of arq.qparse.
It's August now. You'd better hurry up and make the project completed
on time in the remaining weeks.
Best regards,
Ying Jiang
On Thu, Jul 30, 2015 at 6:03 AM, Andy Seaborne a...@apache.org wrote:
Output of
* each examnple syntax file (the queries are nonsense in practcial terms!)
* running arq.qparse on the file
* notes on what seems to be going on
Andy
File: syntax-quad-construct-01.arq
PREFIX : http://example/
CONSTRUCT { GRAPH :g { :s :p :o } } WHERE {}
Output of qparse --file syntax-quad-construct-01.arq
PREFIX : http://example/
CONSTRUCT
{ GRAPH http://example/g {:s :p :o .}
}
WHERE
{ }
Issue:
Minor: formatting of http://example/g should be :g
File: syntax-quad-construct-02.arq
PREFIX : http://example/
CONSTRUCT { GRAPH ?g { ?s ?p ?o } } WHERE { ?s ?p ?o }
Output of qparse --file syntax-quad-construct-02.arq
PREFIX : http://example/
CONSTRUCT
{ GRAPH ?g {?s ?p ?o .}
}
WHERE
{ ?s ?p ?o }
OK
File: syntax-quad-construct-03.arq
PREFIX : http://example/
CONSTRUCT { :s :p :o } WHERE {}
Output of qparse --file syntax-quad-construct-03.arq
PREFIX : http://example/
CONSTRUCT
{ GRAPH urn:x-arq:DefaultGraphNode {:s :p :o .}
}
WHERE
{ }
Issue:
Major: The output is contains GRAPH urn:x-arq:DefaultGraphNode
Note: urn:x-arq:DefaultGraphNode is for internal use only.
For syntax, that is a named graph just like http://example/g
File:
Re: RDFConnection
On Wed, Aug 5, 2015 at 1:14 PM, Andy Seaborne a...@apache.org wrote:
On 04/08/15 22:26, Stephen Allen wrote:
To my knowledge, the only argument for using GSP instead of just
query+update would be performance/scalability. Although, when I have
encountered those issues, I've attempted to fix the problem in
query+update
instead (i.e. adding streaming support for update). However, parsing
large
SPARQL INSERT DATA operations is still slower than parsing NT (not to
mention rdf/thrift). There are potential solutions for that (a
sparql/thrift implementation, even if it only did INSERT/DELETE DATA as
binary and left queries as string blobs), but obviously that doesn't exist
yet.
...
One of the motivating features of jena-client was the ability to perform
large streaming updates (not just inserts/deletes) to a remote store.
This
made up somewhat for the lack of remote transactions. But maybe that
isn't
too great of an argument, when we could just go ahead and implement remote
transaction support (here is a proposal I haven't worked on in over a year
[3]).
GSP is very useful for managing data in a store when combined with a union
of named graphs as the default. Units of the overall graph can be deleted
(bnodes included) and replaced.
It's also useful when scripting management of the data : using curl/wget
you manage a store in simple scripts. Being able to do that in the same
way in Java is helpful so the user does not need two paradigms.
Sure, definitely makes sense. It does seem like we can provide both
mechanisms in a straightforward way.
Fuseki2 provides streaming updates for upload by GSP. RDFConnection has
file upload features so the client-side does not need to parse the file,
just pass an InputStream to HTTP layer.
Makes sense. Jena-client doesn't do that because it has to transform it
into an update query, but obviously pays some penalties while doing that.
RDFConnection adds the natural REST ops on datasets.
Authentication: we should use the HttpOp code - one reason is that it
supports authentication for all HTTP verbs.
Agreed, jena-client uses the HttpOp code.
Jena-client's is more like JDBC
in that the transaction operations are exposed on the Connection object.
If the user chooses not to use the transaction mechanism then it will
default to using auto-commit
Agreed and in fact there an issue here with autocommit, streaming and and
SELECT queries. The ResultSet is passed out of the execSelect operation
but needs to be inside the transaction. Autocommit defeats that.
Yes, I tried to mitigate that with the AutoCommitQueryExecution class. It
wraps the QueryExecution used on a local dataset and then enforces
transactions semantics between the exec*() and close() methods. Obviously
it relies on the user to call close() (or better yet use a
try-with-resources) on the corresponding QueryStatement (they never see the
QueryExecution object directly).
Which touches on the JDBC issue that drivers tend to execute and receive
all the results before the client can start working on the answers
(sometimes there are ways round this to be used with care). The issue is
badly behaved clients hogging resources in the server.
We could default to copying results into memory if we wanted, but provide
an override to disable that.
Some possibilities:
0/ Don't support autocommit. In the local case that is quite natural;
less so for the remote case because HTTP is not about state.
(I looked more at the remote case - e.g. the local connection
implementation isolates results to get the same semantics as remote.)
1/ Autocommit cases receive the results completely. Some idioms don't
work in autocommit more.
2/ An operation to make sure the QueryExecution is inside a transaction
and also closed.
RDFConnection
public default void querySelect(Query query,
ConsumerQuerySolution rowAction) {
Txn.executeRead(this, ()-{
try ( QueryExecution qExec = query(query) ) {
qExec.execSelect().forEachRemaining(rowAction);
}
} ) ;
}
Although I think that using a Consumer like you do in 2) is a great way of
doing things (this is exclusively how we allow queries in our app), perhaps
that functionality should be built as a utility class on top of lower-level
functionality that does let you shoot yourself in the foot if you like.
Then strongly encourage users to do it the safe way.
By the way - I added explicit transaction support and some example usage.
Maybe we can use jena-client as a base to work from? If we feel we want to
add the separate GSP operations, then I think the extension point would be
to add a new GSP interface similar to Updater [5] (but lacking the generic
update query functionality).
I have no problem with jena-client as the starting point, I want to
understand its design first.
I'm not seeing what the separate interfaces and *Statement
[jira] [Commented] (JENA-999) Poor jena-text query performance when a bound subject is used
[
https://issues.apache.org/jira/browse/JENA-999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14659197#comment-14659197
]
Stephen Allen commented on JENA-999:
I'm having some difficulties, and maybe it is my understanding of how property
functions work. The code I recently commited [1] works well for some queries,
but then fails for others. Basically it seems that some queries will build a
new property function object for every iteration of the LHS of the query. So
that even with the code attempting to cache the lucene results, it ends up
issuing a bunch of lucene queries.
I thought I could work around this by checking in the {{build()}} method
whether or not the search term was bound [2] at that point, then doing the
caching there instead of in the {{exec()}} method. But since a new property
function instance is constructed on each query iteration instead of a single
one at plan construction time, that doesn't seem to work either.
My question is whether this is intended behavior for property functions? If it
is, then I may have to fall back to caching the results in the Context object,
with all of the negative downsides outlined above.
I've attached a test program that shows this behavior. It runs well unless it
is inside of a union clause.
[1]
https://github.com/apache/jena/blob/master/jena-text/src/main/java/org/apache/jena/query/text/TextQueryPF.java
[2] The current code has the feature of allowing the search term to be bound
by the query itself. I don't know how useful this is in the real world.
Poor jena-text query performance when a bound subject is used
-
Key: JENA-999
URL: https://issues.apache.org/jira/browse/JENA-999
Project: Apache Jena
Issue Type: Improvement
Reporter: Stephen Allen
Assignee: Stephen Allen
Priority: Minor
Attachments: jena-text benchmarks.png
When executing a jena-text query, the performance is terrible if the subject
is already bound to a variable. This is because the current code will
execute a new lucene query that does not have the subject/entity bound on
every iteration and then iterate through the lucene results to join against
the subject. This is quite inefficient.
Example query:
{code}
select *
where {
?s rdf:type http://example.org/Entity .
?s text:query ( rdfs:label test ) .
}
{code}
This would be quite slow if there were a lot of entities in the system.
Two potential solutions present themselves:
# Craft a more explicit lucene query that specifies the entity URI, so that
the results coming back from lucene are much smaller. However, this would
cause problems with the score not being correct across multiple iterations.
Additionally we are still potentially running a lot of lucene queries, each
of which has a probably non-negligble constant cost (parsing the query
string, etc).
# Execute the more general lucene query the first time it is encountered,
then caching the results somewhere. From there, we can then perform a hash
table lookup against those cached results.
I would like to pursue option 2, but there is a problem. Because jena-text
is implemented as a property function instead of a query op in and of itself
(like QueryIterMinus is for example), we have to find a place to stash the
lucene results. I believe this can be done by placing it in the
ExecutionContext object, using the lucene query as a cache key. Updates
provide a slightly troubling case because you could have an update request
like:
{code}
insert data { urn:test1 rdf:type http://example.org/Entity ; rdfs:label
test } ;
delete { ?s ?p ?o }
where { ?s rdf:type http://example.org/Entity ; text:query ( rdfs:label
test ) . ?p ?o . } ;
insert data { urn:test2 rdf:type http://example.org/Entity ; rdfs:label
test } ;
delete { ?s ?p ?o }
where { ?s rdf:type http://example.org/Entity ; text:query ( rdfs:label
test ) ; ?p ?o . }
{code}
And then the end result should be an empty database. But if the
ExecutionContext was the same for both delete queries, you would be using the
cached results from the first delete query in the second delete query, which
would result in {{urn:test2}} not being deleted properly.
If the ExecutionContext is indeed shared between the two update queries in
the situation above, I think this can be solved by making the cache key for
the lucene resultset be a combination of both the lucene query and the
QueryIterRoot or BindingRoot. I need to investigate this. An alternative,
if there was a way to be notified when a query has finished executing, we
could clear the cache in the ExecutionContext.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JENA-999) Poor jena-text query performance when a bound subject is used
[
https://issues.apache.org/jira/browse/JENA-999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Allen updated JENA-999:
---
Attachment: PerformanceTester.java
Poor jena-text query performance when a bound subject is used
-
Key: JENA-999
URL: https://issues.apache.org/jira/browse/JENA-999
Project: Apache Jena
Issue Type: Improvement
Reporter: Stephen Allen
Assignee: Stephen Allen
Priority: Minor
Attachments: PerformanceTester.java, jena-text benchmarks.png
When executing a jena-text query, the performance is terrible if the subject
is already bound to a variable. This is because the current code will
execute a new lucene query that does not have the subject/entity bound on
every iteration and then iterate through the lucene results to join against
the subject. This is quite inefficient.
Example query:
{code}
select *
where {
?s rdf:type http://example.org/Entity .
?s text:query ( rdfs:label test ) .
}
{code}
This would be quite slow if there were a lot of entities in the system.
Two potential solutions present themselves:
# Craft a more explicit lucene query that specifies the entity URI, so that
the results coming back from lucene are much smaller. However, this would
cause problems with the score not being correct across multiple iterations.
Additionally we are still potentially running a lot of lucene queries, each
of which has a probably non-negligble constant cost (parsing the query
string, etc).
# Execute the more general lucene query the first time it is encountered,
then caching the results somewhere. From there, we can then perform a hash
table lookup against those cached results.
I would like to pursue option 2, but there is a problem. Because jena-text
is implemented as a property function instead of a query op in and of itself
(like QueryIterMinus is for example), we have to find a place to stash the
lucene results. I believe this can be done by placing it in the
ExecutionContext object, using the lucene query as a cache key. Updates
provide a slightly troubling case because you could have an update request
like:
{code}
insert data { urn:test1 rdf:type http://example.org/Entity ; rdfs:label
test } ;
delete { ?s ?p ?o }
where { ?s rdf:type http://example.org/Entity ; text:query ( rdfs:label
test ) . ?p ?o . } ;
insert data { urn:test2 rdf:type http://example.org/Entity ; rdfs:label
test } ;
delete { ?s ?p ?o }
where { ?s rdf:type http://example.org/Entity ; text:query ( rdfs:label
test ) ; ?p ?o . }
{code}
And then the end result should be an empty database. But if the
ExecutionContext was the same for both delete queries, you would be using the
cached results from the first delete query in the second delete query, which
would result in {{urn:test2}} not being deleted properly.
If the ExecutionContext is indeed shared between the two update queries in
the situation above, I think this can be solved by making the cache key for
the lucene resultset be a combination of both the lucene query and the
QueryIterRoot or BindingRoot. I need to investigate this. An alternative,
if there was a way to be notified when a query has finished executing, we
could clear the cache in the ExecutionContext.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
