<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">I'd vote for keeping it, and executing
it lazily in environments where it is costly to compute it upfront.<br>
<br>
And off course, document this properly so users will be aware it
can incur a second execution, with significant performance impact
and also possibly a data visibility/consistency impact. I'd do
this because the api is meant to be first of all user friendly and
useful, not just machine friendly and efficient.<br>
<br>
There's another reason for having it. Say we remove it, how will
users be able to know the total number of matching results? Our
DSL does not currently have a 'count' function. Maybe we should
add such a thing first, and then think about removing
Query.getResultsSize().<br>
<br>
But, if we implement a proper 'count', getResultsSize() could be
trivially implemented as some kind of syntactic sugar on top of
it, so I would still consider it worth being in the API.<br>
<br>
And then it all boils down to the question: <i>should the DSL
provide a count function?</i> (+1 from me)<br>
<br>
Cheers<br>
<br>
On 03/10/2014 02:23 PM, Sanne Grinovero wrote:<br>
</div>
<blockquote
cite="mid:CAFm4XO2tA4U5J=U4f8_g6CE1nia7c1zjNkCN7RX2ao6=amtM1A@mail.gmail.com"
type="cite">
<pre wrap="">Hi all,
we are exposing a nice feature inherited from the Search engine via
the "simple" DSL version, the one which is also available via Hot Rod:
org.infinispan.query.dsl.Query.getResultSize()
To be fair I hadn't noticed we do expose this, I just noticed after a
recent PR review and I found it surprising.
This method returns the size of the full resultset, disregarding
pagination options; you can imagine it fit for situations like:
"found 6 million matches, these are the top 20: "
A peculiarity of Hibernate Search is that the total number of matches
is extremely cheap to figure out as it's generally a side effect of
finding the 20 results. Essentially we're just exposing an int value
which was already computed: very cheap, and happens to be useful in
practice.
This is not the case with a SQL statement, in this case you'd have to
craft 2 different SQL statements, often incurring the cost of 2 round
trips to the database. So this getResultSize() is not available on the
Hibernate ORM Query, only on our FullTextQuery extension.
Now my doubt is if it is indeed a wise move to expose this method on
the simplified DSL. Of course some people might find it useful, still
I'm wondering how much we'll be swearing at needing to maintain this
feature vs its usefulness when we'll implement alternative execution
engines to run queries, not least on Map/Reduce based filtering, and
ultimately hybrid strategies.
In case of Map/Reduce I think we'll need to keep track of possible
de-duplication of results, in case of a Teiid integration it might
need a second expensive query; so in this case I'd expect this method
to be lazily evaluated.
Should we rather remove this functionality?
Sanne
_______________________________________________
infinispan-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/infinispan-dev">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>