On Wed, 3 Feb 2010 17:06:32 -0600 Jonathan Ellis <jbel...@gmail.com> wrote:
JE> It seems to me that the bitmask is only really useful for the JE> SliceRange predicate. Doing a predicate of "fetch these column names, JE> but only if they match this mask" seems strange. You're right, I put it at the wrong level. JE> The mask check needs to be done in the Slice Filter, not SP. Sorry, I don't know what you mean. Are you referring to o.a.c.db.filter.SliceQueryFilter? So I'd just add an extra parameter to the constructor and change the matching logic? Or should I derive a new class for backwards compatibility? I also realized I should have just used a BitSet to do the matching logic for me. JE> Is this actually powerful enough to solve a real problem for you? Yes! OR+AND are exactly what I need. One specific situation: a supercolumn holds byte[] keys representing network addresses (IPv4, IPv6, and Infiniband). I want to do efficient queries across them by various netmasks; the netmasks are not trivial and need the OR+AND structure. Right now I do it all on the client side. I can't break things down by key or by supercolumn further because I already use the supercolumn as a time (Long) index and the key represents the specific colo. I have other examples but they'd require too much explanation of my company's infrastructure. I've seen at least 4 real examples in the last 2 weeks on the dev and user Cassandra mailing lists where some kind of data tagging could be useful instead of just the range query. The original article example that started this thread, for instance, could have used that approach to tag the articles and reduce the need for data duplication. Thanks Ted
