[infinispan-dev] Query.getResultSize() to be available on the simplified DSL?

[Adrian Nistor]

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 <mmarkus at redhat.com> wrote:
>> On Mar 10, 2014, at 15:12, Sanne Grinovero <sanne at 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 pick your battles and be wise on where to spend energy
>>> first.
>>>
>>> Considering that it's easier to add methods than to remove them, what
>>> would you think of marking this as experimental for now?
>>> I'd prefer to see the non-indexed query engine delivered first; this
>>> sounds like being a stone on the critical path so it might be wise to
>>> have the option to drop the requirement from a first implementation.
>>> Definitely you're right that we should then implement "some" COUNT
>>> strategy, I'm just not comfortable in committing on this one yet.
>> I can imagine a lot of users emulating this by simply iterating over the entries in the result set. Even if we do just that and document it as slow, I think it's still worth exposing this somewhere.
> I'm not questioning it to be useful. But the implementation is tricky,
> for example simply iterating would require a global (and distributed)
> lock to be accurate.
> Otherwise we can only document it as an approximation, and worst is we
> can't even estimate an error margin: under steady load it would
> probably be a reasonable estimation, but there are corner cases in
> which you can get off by several orders of magnitude.
> Among others, your assumptions would need to include:
>   - no nodes failing (no state transfers happening)
>   - no write spikes (probably one of the best reasons to deploy
> infinispan is to be able to absorb spikes)
>   - no wild churning across datastore/cachestores
>   - expirations happening in a homogeneus pattern (this entirely
> depends on the use case)
>
> Also there is no way to make this work in the context of a
> transaction, as it would pretty much violate any promise of repeatable
> read properties.
>
> So the question is, if a user would still consider it useful after
> (hopefully) understanding all the attached strings.
>
> In other contexts we discussed the need for Infinispan to provide
> something like a snapshot capability based on TOA. If we had that, we
> could implement a count operation on top of it.
>
> Sanne
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev