On 7/27/2011 3:49 PM, Jonathan Rochkind wrote:
I don't know the answer to feasibilty either, but I'll just point out
that boolean "OR" corresponds to set "union", not set "intersection".
So I think you probably mean a 'union' type of filter query;
'intersection' does not seem to describe what you are describing;
ordinary 'fq' values are 'intersected' already to restrict the result
set, no?
You're right, I noticed that later and corrected myself. Substitute fqu
(and try not to pronounce it) for fqi in my previous message. This is
the only name suggestion I could come up with on short notice, and it's
probably a good idea to change it.
So, anyhow, the basic goal, if I understand it right, is not to
provide any additional semantics, but to allow individual clauses in
an 'fq' "OR" to be cached and looked up in the filter cache individually.
I would like to have both intersection and union at the same time, not
be restricted to one or the other, and have it be possible without
altering existing functionality. The idea is to just add a new
parameter that just changes how the resulting bitset is applied to the
query results. The filterCache entry would look the same whether you
used fq or fqu. Restating my suggested bitset logic with the changed
parameter name:
fq AND fq AND fq AND (fqu OR fqu OR fqu)
It would be awesome to have a syntax that creates arbitrarily complex
and nested AND/OR combinations, but that would be a MAJOR undertaking.
The logic I've mentioned above seems to be the most useful you could get
with just having the one additional parameter. You can get pure union
by just using fqu. The existing model of pure intersection would be
maintained when only fq is present.
Thanks,
Shawn
