Does anyone have a measure of max insertion rate for TDB and/or other
storage implementations? I am trying to determine if it is feasible to use
Jena in an environment with frequent small (7-19 triples) inserts and
infrequent (7x day) reads. This is essentially a system to store some
application
On 27/08/13 06:19, Charles Li wrote:
Hi, Jena experts:
Jena v2.10.1 on Windows 7.
(1) Run TDB loader: loadRDF.cmd myDir myRdfXML.xml.
Don't know what that does.
(2) Create a TDB sitting on myDir:
model = TDBFactory.createDataset(myDir).getDefaultModel();
However, model.size() will
On 27/08/13 00:21, Yuhan Zhang wrote:
thanks for the suggestion, Andy. I'll convert the turtle file and retry it.
It seems their encoding of any odd characters is $, I'm not sure
where that came from. After the report from the 20121223 I thought
they'd clean this up - maybe a new one
On 27/08/13 08:34, Claude Warren wrote:
Does anyone have a measure of max insertion rate for TDB and/or other
storage implementations? I am trying to determine if it is feasible to use
Jena in an environment with frequent small (7-19 triples) inserts and
infrequent (7x day) reads. This is
PS. both the Fuseki and Seki instances are currently wide open, but I'm
pretty sure decent auth won't be too difficult (I'm in the process of
adding auth to Seki, hopefully openshift somewhere will allow me to block
writes to Fuseki outside of the Seki domain). Worst case, it should be
possible to
thanks Andy
Lewis
On Tuesday, August 27, 2013, Andy Seaborne a...@apache.org wrote:
It can certainly be accessed directly - I seem to spend my time stopping
that!
Port 3030 may well be bloked by a firefall somewhere.
We tend to run it behind httpd (or equiv in nginx).
e.g.
VirtualHost
Hallo All,
I just am trying to migrate from jena-incubator-2.7 to apache-jena-2.10.1
I have Windows 7 on a 64 bit platform.
I use additionally cygwin on my platform à This makes problems with arq.
I extracted the zip file and put it into: C:\Jena
I use this shell variables:
I think the problem is that in the cases where this does not apply you
return the original input rather than making a copy so you overwrite
some/all of your changes
Try replacing the following:
return opUnion;
With the following:
return super.transform(opUnion, left, right);
NB - I haven't
On 27/08/13 17:16, Rob Vesse wrote:
I think the problem is that in the cases where this does not apply you
return the original input rather than making a copy so you overwrite
some/all of your changes
Try replacing the following:
return opUnion;
With the following:
return
Hi all,
I'm having some more problems with Fuseki and full text search. I have an
InfModel backed by a TDB dataset, which I've added a Lucene text index to. I'm
having problems with updates and select queries resulting in exceptions being
thrown by Fuseki.
I am running Fuseki 0.2.8-SNAPSHOT
Hi everyone,
I'm using Fuseki 0.2.4 with TDB 0.9.3 (I know that are old version, but
unfortunately I can't change to another version). The problem is the
seguent: I write triples using Fuseki, than I query the dataset (using
Fuseku, of course) and the query returns all values correctly. But If I
But If I
stop the JVM of my Fuseki server (and TDB) from my IDE console, restart
it
and then query the dataset, the query returns to me null values for some
elements of some triples.
How do you stop the JVM? Also what is your TDB setup?
This sounds like one of two things:
1 - Dataset
Stuart - quick question - and from code review, not use test running ...
What was the update? Could it be that there was a syntax error in it?
Andy
On 27/08/13 18:16, Stuart Taylor wrote:
Hi all,
I'm having some more problems with Fuseki and full text search. I have
an InfModel
hey jena folks,
I'm new to this list, so please forgive me if I get something wrong...
my specific questions are at the end of this email, but I wanted to
first describe my problem:
*I am trying to read the latest AIRS OWL (rdf/xml) files, and I'm having
a problem with a particular
Hi, Rob, Andy.
Yes! That solved it!
Thanks a lot!
--
diogo patrão
On Tue, Aug 27, 2013 at 2:04 PM, Andy Seaborne a...@apache.org wrote:
On 27/08/13 17:16, Rob Vesse wrote:
I think the problem is that in the cases where this does not apply you
return the original input rather than
While upgrading to the latest snapshots I noticed some subtle
differences in behavior, related to the deprecation of BulkUpdateHandler
and the corresponding usage of the GraphUtil.add/delete methods. We do
have a very complicating chain of event listeners, delegating graphs
etc, and possibly
16 matches
Mail list logo
