Mailing-List: contact dev-help@clerezza.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@clerezza.apache.org
Received-SPF: error (nike.apache.org: local policy)
Message-ID: <5187C30C.9040907@xup.nl>
Date: Mon, 06 May 2013 16:49:48 +0200
From: Minto van der Sluis <minto@xup.nl>
Organization: Xup BV
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: dev@clerezza.apache.org
Subject: Re: Some Questions regarding implementing fastlane
References: <517A3228.2060101@multimach.com>
 <CALvhUEUVzHDHx7aGHahY-gqi=Mo3zHLMcAY1xH5m92n0vHOhNw@mail.gmail.com>
 <518139A1.9000701@xup.nl>
 <CALvhUEUoQVYwzbsEf5=PEQgbyuFaS3Qt2vXuLkSgeapondC5Pw@mail.gmail.com>
In-Reply-To: 
 <CALvhUEUoQVYwzbsEf5=PEQgbyuFaS3Qt2vXuLkSgeapondC5Pw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Thanks Reto,

This clarifies the difference between fast-lane and slow-lane.

Regards,

Minto

Op 5-5-2013 19:37, Reto Bachmann-Gm�r schreef:
> Hi Minto
>
> Great work updating the modules!
>
> Now to the questions.
>
>
>
>>> - Forward query to fast- or slowlane using the Preparerser Hasan recently
>>> implemented
>> Questions: Where is this decision taken? How to decide whether to use
>> QueryEngine of QueryableTcProvider ? Are these both fast-lane?
>>
> (Deferring the where question to when I write the code.)
> The QueryEngine is the slow-lane it works on any set of TripleCollections.
> QueryableTcProvider is the FastLane in that it might benefit from any
> optimization the backend provides it can only be used if the query only
> affects TripleCollections that are all provided by the same TcProvider (and
> this implements QueryableTcProvider).
>
>> - Make TdbTcProvider implement QueryableTcProvider
>> Question: Why is this needed if JenaSparqlEngine (implementation of
>> previous bullet) already takes care of this?
>>
> The JenaSparqleEngine works on any TripleCollections which are passed to
> Jena wrapped as Jena Graphs. JenaSparqlEngine can only access the data in
> these graphs via the provided filter method. The assumption is that TDB can
> handle (some) queries more efficiently by using its internal quad-store or
> other optimization techniques it could provide.
>
>> Of coarse I could wire Tdb*Providers to use JenaSparqlEngine. But I
>> don't see the point.
>>
> This shouldn't be wired to JenaSparqlEngine (only probably reuse response
> wrapping code) but forward the query directly to Jena rather than wrapping
> JenaGraphs as TripleCollections in the Tdb*Provider and wrapping these back
> to Jena Graphs for querying in the JenaSparqlEngine.
>
> Hope this makes things clearer.
>
> Cheers,
> Reto
>


-- 
ir. ing. Minto van der Sluis
Software innovator / renovator
Xup BV

Mobiel: +31 (0) 626 014541