On 13/08/2021 12:03, jaa...@kolumbus.fi wrote:
Andy Seaborne kirjoitti 11.8.2021 17:38:
Hi there,
There isn't enough information to see what's happening.
Hello,
see steps to repeat the issue below.
I've got all the parts of the example - it's not minimal though.
What is a short amount of data, shorter update script that shows the
problem?
Does it need the data pulled from another server that than execute on
already loaded data?
There is a data file of 363,559 quads (which has warnings), a SPARQL
update script of 241 lines.
To work out what is going on, someone has to reduce that large setup to
the part that causes the difference.
The first thing that script does is delete all the local data and pull
some, not all, data from the source server. Is that step necessary?
I don't believe it needs all the data and all the script to show a
difference nor that it needs to pull the data out of one server, and put
it in the local store in order to be different, why not just load
something directly?
The rest of the update does some kind of manipulation of the data - I
don't understand what it is trying to do - its purpose relates the to
data model.
You are in a much better place to reduce that large script to a minimal
one that shows a difference because it's your application.
Does it need all those steps together to show the difference or just one
of them? (BTW each update step is done independency: there'll be a
point where the answers start diverging.)
Looking at it though, the use of
where{
{
graph ?g { }.
}
graph ?g {
.. some pattern ..
.. some BIND involving ?g ..
}
}
is pretty suspect.
Omit the first part and put the BIND after the second:
Move the BIND to after the
graph ?g {
.. some pattern ..
}
.. some BIND involving ?g ..
Andy
Where is the 3.13.0 server?
1) start source apache-jena-fuseki-server on port 3030
2) start target apache-jena-fuseki-3.17.0-server on port 3031
3) unzip and upload the attachment ds.zip into source
apache-jena-fuseki-server on port 3030 using command
curl -XPOST --header 'Content-Type: application/trig'
--data-binary @ds.trig http://<source
apache-jena-fuseki-server>:3030/<source dataset>
4) create one in-memory dataset and one persistent dataset on target
apache-jena-fuseki-3.17.0-server
5) update the source apache-jena-fuseki-server and source dataset in
combine_NGs.sparql-file
6) run combine_NGs.sparql-script in in-memory dataset and persistent
dataset of the target apache-jena-fuseki-3.17.0-server
Run how?
7) run query
SELECT ?subject ?predicate ?object
WHERE {
?subject ?predicate ?object
}
in in-memory dataset and persistent dataset of the target
apache-jena-fuseki-3.17.0-server and compare the results.
See attachements in_memory.png and persistent.png for my results after
the above procedure.
That's screenshots of a count: just do
SELECT (Count(*) AS ?C) { ?s ?p ?o }
Jaana
The first thing to do is dump, or Fuseki backup, the database from
each setup and see if they are the same.
Then if they are, send a minimal reproducible example [1].
Something someone else can run.
Andy
[1]
https://stackoverflow.com/help/minimal-reproducible-example
On 11/08/2021 13:35, jaa...@kolumbus.fi wrote:
Hello,
My jena-fuseki database consists of several named graphs. In order to
provide users graphql-like interface to jena-fuseki I have to combine
my NGs into one big default graph for HyperGraphql
(https://www.hypergraphql.org/) that provides the interface.
At some point the users started to get less data than before and when
I investigated the issue I noticed that this was after upgrading
jena-fuseki from 3.13 to 3.17 !
To combine the NGs I'm using the following command:
curl -i -H "Content-Type: application/sparql-update" -X POST
http://<myTargetHost>:8061/<myDs>/update --data-binary
"@./combine-NGs.sparql"
(see NGs_to_be_combined.txt for hint of my source database and
combine-NGs.sparql as the executed script).
So I run the combine-NGs.sparql-script in the target jena host and
the target dataset.
If I use in-memory dataset as my target dataset I get only half of
the triplets cmapared to the amount of triplets with persistent
dataset. This happens only with jena-fuseki 3.17.
In 3.13 I haven't seen this issue!
Br, Jaana
