Maybe a Long rather than an Integer? Ints are so last year. :-) And, what about using a primitive that returns -1 when the method cannot determine the size (if allowed by the parameter). Just as easy to check -1 than it is to check null, IMO.
On Mar 11, 2014, at 2:21 PM, Emmanuel Bernard <[email protected]> wrote: > It does not work, I think, because if you implement your query via some map > reduce and you do pagination, it will be costly to compute the size and you > might want not to return it. > Hence my Accuracy idea to clarify the intend to the API user. > > On 11 Mar 2014, at 19:18, Sanne Grinovero <[email protected]> wrote: > >> what about we call it >> >> int getEstimatedResultSize() ? >> >> Having such a method occasionally return null looks very bad to me, >> I'd rather remove the functionality. >> >> -- Sanne >> >> On 11 March 2014 19:08, Emmanuel Bernard <[email protected]> wrote: >>> I agree with Randall. >>> >>> I tend to be very conservative about my public APIs. And offering an API >>> that I think will block me in the future is something I tend to avoid. >>> >>> Something like .guessNbrOfMatchingElements() / .guessResultSize() would >>> provide a better clue about the gamble the user takes. Note that the size >>> is irrespective of the pagination applied which renders this result quite >>> cool even if approximate. >>> >>> I’d be tempted not to put getResultSize() with an exact value in the public >>> contract as iterating is probably going to as “fast”. >>> >>> An alternative is something like that (needs to be refined though) >>> >>> /** >>> * Get the result size. >>> * Approximate results are to be preferred as it is usually very cheap to >>> compute. >>> * If the computation is too expensive, the approximate accuracy returns >>> null. >>> * >>> * Exact results are likely to be costly and require two queries. >>> */ >>> Integer getResultSize(Accuracy); >>> enum Accuracy { EXACT, APPROXIMATE_OR_NULL } >>> >>> Emmanuel >>> >>> On 11 Mar 2014, at 18:23, Randall Hauch <[email protected]> wrote: >>> >>>> I disagree. Most developers have access to the JavaDoc, and if even >>>> moderately well-written, they will find out what the method returns and >>>> when. It’s no different than a method sometimes returning null rather than >>>> an object reference. >>>> >>>> On Mar 11, 2014, at 12:16 PM, Dennis Reed <[email protected]> wrote: >>>> >>>>> Providing methods that work sometimes and don't work other times is >>>>> generally a bad idea. >>>>> >>>>> No matter how much you document it, users *will* try to use it and >>>>> expect it to always work >>>>> (either because they didn't read the docs that say otherwise, they think >>>>> they'll stick to a configuration where it does work, etc.) >>>>> >>>>> And then when it doesn't work (because they pushed something to >>>>> production which has a different configuration than dev, etc) >>>>> it's a frustrating experience. >>>>> >>>>> -Dennis >>>>> >>>>> On 03/11/2014 09:37 AM, Randall Hauch wrote: >>>>>> I’m struggling with this same question in ModeShape. The JCR API exposes >>>>>> a method that returns the number of results, but at least the spec >>>>>> allows the implementation to return -1 if the size is not known (or very >>>>>> expensive to compute). Yet this still does not satisfy all cases. >>>>>> >>>>>> Depending upon the technology, computing the **exact size** ranges from >>>>>> very cheap to extremely expensive to calculate. For example, consider a >>>>>> system that has to take into account access control limitations of the >>>>>> user. My current opinion is that few applications actually need an exact >>>>>> size, and if they do there may be alternatives (like counting as they >>>>>> iterate over the results). >>>>>> >>>>>> An alternative is to expose an **approximate size**, which is likely to >>>>>> be sufficient for generating display or other pre-computed information >>>>>> such as links or paging details. I think that this is sufficient for >>>>>> most needs, and that even an order of magnitude is sufficient. When the >>>>>> results are known to be small, the system might want to determine the >>>>>> exact size (e.g., by iterating). >>>>>> >>>>>> So one option is to expose both methods, but allow the exact size method >>>>>> to return -1 if the system can’t determine the size or if doing so is >>>>>> very expensive. This allows the system a way out for large/complex >>>>>> queries and flexibility in the implementation technology. The >>>>>> approximate size method probably always needs to return at least some >>>>>> usable value. >>>>>> >>>>>> BTW, computing an exact size by iterating can be expensive unless you >>>>>> can keep all the results in memory. That’s not ideal - a query with >>>>>> large results could fill up available memory. If you don’t keep all >>>>>> results in memory, then if you’re going to allow clients to access the >>>>>> results more than once you have to provide a way to buffer the results. >>>>>> >>>>>> >>>>>> On Mar 10, 2014, at 7:23 AM, Sanne Grinovero <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> 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 >>>>>>> [email protected] >>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>>>> >>>>>> _______________________________________________ >>>>>> infinispan-dev mailing list >>>>>> [email protected] >>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>>> >>>>> _______________________________________________ >>>>> infinispan-dev mailing list >>>>> [email protected] >>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>> >>>> >>>> _______________________________________________ >>>> infinispan-dev mailing list >>>> [email protected] >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> [email protected] >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> _______________________________________________ >> infinispan-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
