Unfortunately, the most recent version of the snapshot
(apache-jena-fuseki-0.2.1-incubating-SNAPSHOT) has not fixed my problem.
I've had a chance to pair this down to a set small enough to replicate
the problem, at least on my end.
Starting with this file:
~/RDF/minimal.ttl:
------------------
@prefix eg: <http://example.org/ontology#>.
eg:dummySubject1 eg:dummyPredicate1 eg:dummyObject1.
-----------------
I call:
> tdbloader2 --loc ./TDB/minimal/ ./RDF/minimal.ttl
To index a TDB repo.
Now given this configuration file:
EG/services-config.ttl
----------------------
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix fuseki: <http://jena.apache.org/fuseki#> .
@prefix ja: <http://jena.hpl.hp.com/2005/11/Assembler#> .
@prefix tdb: <http://jena.hpl.hp.com/2008/tdb#> .
@prefix eg: <http://example.org/ontology#>.
<> rdfs:label "Fuseki Configuration File" .
<#server> rdf:type fuseki:Server ;
fuseki:services
(
<#minimalService>
)
.
<#minimalService>
rdf:type fuseki:Service ;
fuseki:name "minimal";
fuseki:serviceQuery "query";
#enables <form action="query">...</form> in html
fuseki:serviceUpdate "update";
#enables <form action="update">...<form> in html when fuseki-server is
called with --update option.
fuseki:serviceUpload "upload";
#Non-sparql upload service.
fuseki:serviceReadWriteGraphStore "data"; #
enables s-put
fuseki:dataset <#minimalDataset>;
.
[] ja:loadClass "com.hp.hpl.jena.tdb.TDB" .
tdb:DatasetTDB rdfs:subClassOf ja:RDFDataset .
tdb:GraphTDB rdfs:subClassOf ja:Model .
<#minimalDataset> rdf:type ja:RDFDataset;
ja:defaultGraph <#minimalGraph>.
<#minimalGraph> rdf:type tdb:GraphTDB;
tdb:location "/home/escott/TDB/minimal/".
---------------------- end services-config.ttl
I call:
> fuseki-server --config=./EG/services-config.ttl --update &
Then:
> s-query --service http://localhost:3030/minimal/query 'SELECT * {?s
?p ?o}'
gives:
{
"head": {
"vars": [ "s" , "p" , "o" ]
} ,
"results": {
"bindings": [
{
"s": { "type": "uri" , "value":
"http://example.org/ontology#dummySubject1" } ,
"p": { "type": "uri" , "value":
"http://example.org/ontology#dummyPredicate1" } ,
"o": { "type": "uri" , "value":
"http://example.org/ontology#dummyObject1" }
}
]
}
}
... as expected.
Then given a file EG/test-insert.sparql:
-------------------
PREFIX eg: <http://example.org/ontology#>
INSERT DATA
{
eg:dummySubject1 eg:dummyPredicate2 eg:dummyObject2.
}
-------------------
Entering:
> s-query --service http://localhost:3030/minimal/query 'SELECT * {?s
?p ?o}'
gives:
{
"head": {
"vars": [ "s" , "p" , "o" ]
} ,
"results": {
"bindings": [
{
"s": { "type": "uri" , "value":
"http://example.org/ontology#dummySubject1" } ,
"p": { "type": "uri" , "value":
"http://example.org/ontology#dummyPredicate1" } ,
"o": { "type": "uri" , "value":
"http://example.org/ontology#dummyObject1" }
} ,
{
"s": { "type": "uri" , "value":
"http://example.org/ontology#dummySubject1" } ,
"p": { "type": "uri" , "value":
"http://example.org/ontology#dummyPredicate2" } ,
"o": { "type": "uri" , "value":
"http://example.org/ontology#dummyObject2" }
} ,
{
"s": { "type": "uri" , "value":
"http://example.org/ontology#dummyPredicate2" }
}
]
}
}
...Huzzah!
BUT - killing the process and restarting with the same arguments does
*not* persist the results, and all I get is the one original triple.
Is there something I'm doing wrong, or is this a bug? If so, I hope this
gives you enough of a basis to replicate the problem on your side.
Thanks as always for your help.
On 01/15/2012 09:28 AM, Andy Seaborne wrote:
Eric,
That needs investigating - it should work. It looks like it might be
connected to Audun's report "Problem persisting N-Triples" as this
erroneous behaviour is characteristic of unflushed caches.
Could you tell me what
fuseki-server --version
reports?
Could you also say what's in the configuration file?
Andy
On 14/01/12 20:32, Eric Scott wrote:
I'm playing with Fuseki using a config file:
fuseki-server --config <config-file> --update dataset
Where <config-file> declares several services, all of which have
associated tdb files.
When I use:
s-update --file <sparql-file> --service
http://localhost:3030/myService/update
The update works just fine, but update does not persist if I kill the
fuseki-server and restart with the same arguments. I note that several
files within the associated TDB directory have updated timestamps, but
querying against the new inserts produces an empty result set.
Are there config options or something else one needs to provide in order
to ensure such persistence?
Thanks,