I find checking null a bit cleaner. -1 is so C :) but that's relatively
minor and we can go either way.
On 11 mars 2014, at 21:59, Randall Hauch rha...@redhat.com wrote:
Maybe a Long rather than an Integer? Ints are so last year. :-)
And, what about using a primitive that returns -1
On 10 March 2014 17:09, Mircea Markus mmar...@redhat.com wrote:
On Mar 10, 2014, at 15:12, Sanne Grinovero sa...@infinispan.org wrote:
Ok you make some good points, and I've no doubts of it being useful.
My only concern is that this could slow us down significantly in
providing other
I think that technical trickiness is also required for implementing
pagination, and would probably also suffer from same
limitations/approximations.
Should we remove pagination too from the api?
On 03/11/2014 10:47 AM, Sanne Grinovero wrote:
On 10 March 2014 17:09, Mircea Markus
To be more precise, by pagination I'm referring to methods
QueryBuilder.startOffset/maxResults. Since our remote protocol are
stateless we would need to re-execute the query to fetch the next page.
That leads to the same problem of approximation.
On 03/11/2014 03:11 PM, Adrian Nistor wrote:
I
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
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
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
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.
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 emman...@hibernate.org wrote:
I agree with Randall.
I tend to be very conservative
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
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
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
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
Ok you make some good points, and I've no doubts of it being useful.
My only concern is that this could slow us down significantly in
providing other features which might be even more useful or pressing.
You have to pick your battles and be wise on where to spend energy
first.
Considering that
On Mar 10, 2014, at 13:16, Adrian Nistor anis...@redhat.com wrote:
I'd vote for keeping it, and executing it lazily in environments where it is
costly to compute it upfront.
from a user perspective I see a lot of reason to have this in.
And off course, document this properly so users
On Mar 10, 2014, at 15:12, Sanne Grinovero sa...@infinispan.org wrote:
Ok you make some good points, and I've no doubts of it being useful.
My only concern is that this could slow us down significantly in
providing other features which might be even more useful or pressing.
You have to
16 matches
Mail list logo
