Community
Participate
Working Groups
It's often valuable to know if query returns a single item, however this is not easy with our current API. You either have to covert the result to Set (a potentially costly operation), or start iterating through the results. We have a convenience method to determine if a Query result is empty or not. It might be valuable to add a similar method to determine if there is *exactly* one element in the result set. I don't think this should be expensive to calculate.
I've seen a case in the past week where someone introduced an O(n) computation to find the size of a query result: queryable.query(InstallableUnitQuery.ANY, null).toArray(IInstallableUnit.class).length; Since removing the size() method doesn't actually stop people from needing to compute the size of the result, I would even be in favor of adding it back. It could always return -1 for "unknown" size if we ever created a lazy result implementation. If we're providing IQueryResult#toArray I don't see why we can't have IQueryResult#size, since the size method is never going to be more expensive to perform than the toArray method.
I went through our code in the search for a place where we were trying to compute the size of the QueryResult and at this point I only found a handful of matches (less than 5, actually I saw only one in the Projector) in the real code. Sure the tests have more of these but I don't see this has a being an argument to add new methods. That said, I may have miss some references and would appreciate more details of where problems are happening. Ian what are the cases where you need to know the size?
I didn't find to many places where I needed to know the actual size, but there were some cases where I wanted to know if there was exactly 1 thing. Usually the code went like this: If there is one thing, good! If there is more than 1, hum... but let's deal If there is none, not really expected -- log it, etc... Things like finding the host(s) of a fragment, or a particular bundle by name lead to this coding pattern.
Bad use of an interface often signify that something needs to be done with the interface. That's the very reason for removing size(). We had numerous places where size() > 0 was used instead of isEmpty(). I'm convinced we will see that again if size() is reintroduced. We need to document the interface and make people aware of the reason behind the design decisions. One thing that proves that point is that I already see lots of places where the expensive method toSet() is used instead of the cheap method unmodifiableSet() just to return something that can be added to another set. A method like: boolean hasSingleResult() could be implemented since it can be backed by a copying iterator but if it's only useful in a few places, I would rather keep the API as small as possible.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
