So following this up further.  I got the 0.2.1-incubating-SNAPSHOT building, 
made my changes to enable FROM/FROM NAMED and ran it locally via Eclipse

I loaded the same data, in the same way using a TDB memory dataset (--mem 
option) like my previous email and still saw the same incorrect behavior, FROM 
clauses do not seem to be respected by TDB

So what I found was that I did need to also alter decideDataset() so that 
DynamicDatasets.dynamicDataset() will be used to create the dataset and then 
that exhibits the correct behavior.

I will write up some tests for this and then go ahead and submit a patch via 
JIRA if that is ok?

Rob Vesse

-----Original Message-----
From: Robert Vesse [mailto:[email protected]] 
Sent: Wednesday, November 09, 2011 10:24 AM
To: [email protected]
Subject: RE: Adding FROM/FROM NAMED support to Fuseki?

So to follow up on this

Using the 0.2.1-SNAPSHOT even with FROM/FROM NAMED allowed TDB does not behave 
correctly.  The only change I made to the snapshot code was to disable the 
error on FROM/FROM NAMED, I removed my attempts at changing the dataset in 
decideDataset() and left the default behavior in place.

I put a couple of triples in the default Graph and a couple in a named Graph.

Doing the following showed the triples in their correct graphs:

SELECT * WHERE { { ?s ?p ?o } UNION { GRAPH ?g { ?s ?p ?o } } }

Doing the following shows just the triples in the default graph selected:

SELECT * WHERE { ?s ?p ?o }

Doing the following which I'd expect to give the triples from the named graph 
instead gave back the triples from the default graph:

SELECT * FROM <http://example.org/graph> WHERE { ?s ?p ?o }

Which dev branch are you talking about here?  Are you talking about the 
0.2.1-incubating-SNAPSHOT which for the record is really awkward to build right 
now as the only way to do it seems to be to check out the Trunk of each 
component into adjacent directories and then run mvn commands.  This is kinda 
really clunky particularly if you do the typical thing of checking out the 
entire repo (or at least the component you care about) only to find it is not 
buildable without a specific directory structure.

I have about got this in place and building so will go ahead and test against 
that and see if that works for me and get back to you

Regards,

Rob Vesse



-----Original Message-----
From: Robert Vesse [mailto:[email protected]] 
Sent: Wednesday, November 09, 2011 8:45 AM
To: [email protected]
Subject: RE: Adding FROM/FROM NAMED support to Fuseki?

Ok, we're working against the 0.2.0 Fuseki codebase atm so will try against the 
development branch and see what happens

Thanks,

Rob

-----Original Message-----
From: Andy Seaborne [mailto:[email protected]] On Behalf Of Andy 
Seaborne
Sent: Wednesday, November 09, 2011 5:19 AM
To: [email protected]
Subject: Re: Adding FROM/FROM NAMED support to Fuseki?

On 08/11/11 23:11, Robert Vesse wrote:
> Hi Andy
>
> So my approach certainly works as far as constructing a dataset goes
> but it still doesn't do what I wanted it to do.  The problem is that
> it goes away and builds a fresh dataset from scratch based on the
> URIs that get passed to it.  So when I tested it against TDB I find
> that whenever I specify a FROM/FROM NAMED I get the wrong results
> because it builds the dataset by loading the

"loading the" ??? URL from the web?

Fuseki does this when the request is to the general query processor (on 
"/sparql" and code in SPARQL_QueryGeneral).

I commented out the code in SPARQL_QueryDataset.validateQuery which 
checked for FROM/FROM NAMED.  Then I made a query to a TDB dataset is 
getting to TDB and triggering dynamic dataset processing.

(current development codebase)

Yes, QueryEngineTDB creates a new DatasetGraph internally but it's 
rooted to the database but I'm guessing this is what you mean.

> What I want it to do is to pull out the graphs to be used from the
> underlying storage but I have no idea whether that is in any way
> possible?  Perhaps you can enlighten me on this because I can't see
> any obvious way of doing this in code.

> If this is not possible then we're stuck with just disabling the
> error thrown when FROM/FROM NAMED is specified and hoping that the
> underlying store supports this feature somehow but certainly TDB
> appears to ignore it entirely.

TDB does not ignore it - see QueryEngineTDB and 
DynamicDatasets.dynamicDataset.

        Andy

Reply via email to