It seems to me that the bitmask is only really useful for the SliceRange predicate. Doing a predicate of "fetch these column names, but only if they match this mask" seems strange.
The mask check needs to be done in the Slice Filter, not SP. Is this actually powerful enough to solve a real problem for you? -Jonathan 2010/2/3 Ted Zlatanov <t...@lifelogs.com>: > On Mon, 1 Feb 2010 11:14:12 -0600 Jonathan Ellis <jbel...@gmail.com> wrote: > > JE> 2010/2/1 Ted Zlatanov <t...@lifelogs.com>: >>> On Mon, 1 Feb 2010 10:41:28 -0600 Jonathan Ellis <jbel...@gmail.com> wrote: >>> > JE> I don't think this is very useful for column names. I could see it > JE> being useful for values but if we're going to add predicate queries > JE> then I'd rather do something more general. >>> >>> Do you have any ideas? > > JE> Not really, no. I think we're best served developing feature X by > JE> starting with problems that can only be solved with X and working from > JE> there. Going the other direction is asking for trouble. > > I looked at the filters, e.g. o.a.c.db.filter.SliceQueryFilter, and it > seems like one place to put predicate logic is in that hierarchy. > Perhaps there can be a PredicateQueryFilter. Some thought has > apparently already gone into flexible filters at the storage level. I > hope something happens in this direction but I won't push for it > further since it's not what I need. > > The attached patch is how I propose to do bitmasks inside the > SlicePredicate. As you suggested, it solves the specific problem. It's > pretty simple and carries no performance penalty if bitmasks are not > used. It's untested, intended to show the interface and approach I am > proposing. I didn't open an issue since it's unclear that this is the > way to go. > > Thanks > Ted > >
