[KinoSearch] KinoSearch: Patch extending query language in 0.15.

Matthew O'Connor matthew.oconnor at socialtext.com
Thu Sep 6 18:10:15 PDT 2007


On Sep 6, 2007, at 4:33 PM, Marvin Humphrey wrote:

>
> On Sep 6, 2007, at 4:07 PM, Matthew O'Connor wrote:
>
>> Marvin, (resending to list)
>
> Thanks, I definitely prefer to handle this sort of thing out in the  
> public forum.  :)
>
>> So if I have field "foo" and terms "bar" and "baz" then "foo:(bar  
>> baz)" is equivalent to "(foo:bar foo:baz)".  The expression "foo: 
>> (bar baz)" formerly had no semantics, but my implementation seems  
>> like a reasonable interpretation.
>
> I think this is a very nice improvement in terms of consistency.

While testing this patch at Socialtext we ran into a few surprises,  
which I am not sure are wrong.  I originally intended that "foo:(bar  
baz)" would be the same as "foo:bar foo:baz" regardless of what foo,  
bar, and baz were.  However, that's certainly not the case when "bar"  
or "baz" end in a colon.

In the case of "foo:(bar: baz)" we have that being the same as  
"bar:baz" and not "foo:bar: foo:baz" as I originally thought.  I  
think this is probably okay and that the way it works, even though I  
didn't intend that, is probably less surprising on the whole.  One  
generally expects their "tag:" prefixes to have an effect and having  
them not would be weird.

Does that make sense?  And if so, do you agree?

> The underlying functionality is needed because of how your patch  
> works (kudos on its simplicity and elegance, BTW), but I think we  
> ought to leave that second argument private.  It's not needed  
> because the constructor allows you to specify custom fields already  
> and we're just duplicating that functionality.  If you really need  
> to set up custom fields, you can create multiple QueryParser  
> objects -- they aren't cumbersome.

I agree, leaving it private is probably for the best.   I was just  
being a dutiful documenter.   I removed it from the patch and reattched.


-matthew

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 001-field-on-boolean-group.patch
Type: application/octet-stream
Size: 2204 bytes
Desc: not available
Url : http://rectangular.com/pipermail/kinosearch/attachments/20070906/65f4d2f9/attachment-0002.obj 
-------------- next part --------------
_______________________________________________
KinoSearch mailing list
KinoSearch at rectangular.com
http://www.rectangular.com/mailman/listinfo/kinosearch


More information about the kinosearch mailing list