These are the OpExecutor's methods that I extended:

protected QueryIterator execute(OpFilter opFilter, QueryIterator input)
protected QueryIterator execute(OpBGP opBGP, QueryIterator input)

Did I miss other methods to extend?

Thanks,
Z
________________________________________
From: Andy Seaborne <[email protected]>
Sent: Monday, November 16, 2015 5:18 PM
To: [email protected]
Subject: Re: total triples

On 16/11/15 21:00, Zen 98052 wrote:
> Hi Andy,
> Apologize for my lacking knowledge on Jena codebase, I am still learning at 
> slow pace.
>
> I guess the stuff in OpExecutor is the algebra that you referred to, right? 
> If yes, then the answer is I have implemented some of them.
> I looked at Jena's code, and found AggCount class, is that the one I should 
> subclass? And where would be the integration point with my code?
> Right now for this query, "SELECT (COUNT(*) AS ?no) { ?s ?p ?o }", my code 
> will bind all those variables :-(
> I guess my code needs to behave same like TDB, so when it sees COUNT(*), it 
> won't bind those variables, and instead just counting number of rows.
> If there is existing sample code in Jena's repo, which does exactly what I am 
> looking for, then that'd be helpful too.
>

Which parts of OpExecutor have you extended?  If it's the places to hook
in to graph access, then you will not need to do anything.

Aggregation builds on top of the pattern matching and grouping.

It still won't call graphBaseSize - it's general so it might be COUNT(*)
a GROUP BY, not just { ?s ?p ?o }

        Andy

>
> Thanks,
> Z
> ________________________________________
> From: Andy Seaborne <[email protected]>
> Sent: Monday, November 9, 2015 2:50 PM
> To: [email protected]
> Subject: Re: total triples
>
> On 09/11/15 18:58, Zen 98052 wrote:
>> Thanks Martynas!
>> Shouldn't it call graph's size(), which in turn calls graphBaseSize()?
>
> Depends what "it" is.  Have you implemented some or all of the algebra
> or are you using the general query engine over a graph/dataset?
>
> ARQ's general query engine does not call Graph.size.
>
> COUNT(*) is a general operator and COUNT(*) means count rows.
>
> So it counts the rows of the pattern:
>
> other queries work:
>
> SELECT (COUNT(*) AS ?no) {
>      { <someuri> ?p ?o } UNION { GRAPH ?g { <someuri> ?p ?o } } }
>
> (TDB uses delayed evaluation of results so it never pulls the real nodes
> for variables in COUNT(*)).
>
>          Andy
>
>
>> My graph implementation overrides graphBaseSize(), but looks like it never 
>> got called for that query.
>>
>> Thanks,
>> Z
>> ________________________________________
>> From: Martynas Jusevičius <[email protected]>
>> Sent: Monday, November 9, 2015 9:52 AM
>> To: [email protected]
>> Subject: Re: total triples
>>
>> That would only count triples in the default graph and omit triples in
>> named graphs. To account for them, you would need something like
>>
>> SELECT (COUNT(*) AS ?no) { { ?s ?p ?o } UNION { GRAPH ?g { ?s ?p ?o } } }
>>
>> On Mon, Nov 9, 2015 at 3:47 PM, Zen 98052 <[email protected]> wrote:
>>> What is the most efficient way to get total number of triples?
>>>
>>> Is this query below the only way?
>>>
>>> SELECT (COUNT(*) AS ?no) { ?s ?p ?o }
>>>
>>>
>>> Thanks,
>>>
>>> Z

Reply via email to