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 <[email protected]> wrote: >> On Mar 10, 2014, at 15:12, Sanne Grinovero <[email protected]> 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 > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
