clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reto Bachmann-Gmür <>
Subject Re: ForceFastlane
Date Mon, 15 Jul 2013 10:07:50 GMT
Hi Minto

On Mon, Jul 15, 2013 at 11:18 AM, Minto van der Sluis <> wrote:
> Hi Reto,
> A bit more information about my situation. We do NOT have a few graphs
> with lots of triples. We have a large number of graphs with a few
> triples. Currently I am testing with 20,000 graphs with in total 700,000
> triples. So approximately 35 triples per graph. In production the number
> of graphs will most propably be much larger.
> Think of what I am doing as sort of a subclass of OpenAnnotation with a
> single graph per annotation. This top level annotation is what we call
> an annotation trunk. To make it more complicated these top level
> annotations can be annotated themselves with for examples status,
> attachments and other stuff. These lower level annotations are stored in
> the same graph as the top level annotation that is being annotated.
> Might sound a bit funny but I am trying to be brief here.
> Most of the queries that I run is about finding the graphs that match
> certain criteria. I do not have a FROM clause in my queries, but I do
> use GRAPH in my WHERE clauses. My queries match the following template:
>    SELECT ?graphId ...
>    WHERE {
>       GRAPH ?graphId {
>           ...
>       }
>    }

so basically you're not using  default graph. That's fine, we shoud
just support usecases with default graph too.

> See some other remarks below:
> Regards,
> Minto
> Op 14-7-2013 22:12, Reto Bachmann-Gmür schreef:
>> Hi minto
>> I'm wondering if the method
>> executeSparqlQuery(String query, TripleCollection defaultGraph,
>> boolean forceFastlane)
>> is justified.
>> if forceFastlane is true the defaultGraph is necessarily ignored. If
>> there is a usecase for such a method we could as well have a special
>> method without the defaultGraph for queries that must have a FROM
>> clause:
>> executeSparqlQuery(String query, boolean forceFastlane)
> This would suit my needs. Then I no longer need to create a dummy empty
> graph. But how should it work if fastlane is disabled (false). If we
> revert to QueryEngine then it requires a tripleCollection again.

I don't see the problem. The above methods should only be used when
the query does not access the default graph. So if we have to pass the
query to the QueryEngine it doesn't matter what the default graph is
(e.g we would just pass an empty graph).

> Also, the following line seems like a hack or code smell to me.
>     final UriRef defaultGraphName = new
> UriRef("urn:x-temp:/kjsfadfhfasdffds");

It's a hack, but imho not a smelly one :)

A non-hack solution would be that rather to pass the defaultGraph name
to the preparser the preparser returns referenced graphs and a boolean
telling us whether the default graph is used.

Maybe we could address this together with the security issue. So we
have the perparser with a single method

QueryAnalysis preParse(String query)

where QueryAnalysis would have the following fields:

graphReadAccessed: Set<UriRef>  //not including those in graphWriteAccessed
graphWriteAccessed: Set<UriRef>
defaultGraphAcessed: Enum {NONE, READ, WRITE}


View raw message