Support multiple values per key+discussion
I basically just got :in working, but it works on types now, which is the single biggest issue we've faced.
--Ethan McCutchen.....Wed Mar 18 18:15:33 -0700 2009
(in only works with properties)
--John Abbe.....Mon Mar 23 11:02:56 -0700 2009
Has more been done on this? I.e., do i need to test other uses of in, or just bang on some weird cases around using it with types?
--John Abbe.....Sun Apr 05 19:01:57 -0700 2009
See http://sandwagn.wagn.org/wagn/WQL_testing
--John Abbe.....Thu Apr 16 14:55:15 -0700 2009
"in" is an operator. you can't have two operators in any one expression. and "in" is the *only* operator that takes multiple values.
so you can do name=>[in,A,B], type=>[in,A,B], or content=>[in,A,B] (which is the same as just in=>[A,B]), but you can't do eq=>[in,A,B] or =>[in,A,B].
All of the errors are with searches attempting to combine multiple operators in a single statement (out of spec), except for the plus card ones, which is designed but beyond the scope of this ticket (this is only for properties; plus is a relationship).
--Ethan McCutchen.....Thu Apr 16 21:22:47 -0700 2009
There's syntax in CQL+Design that supports multiple operators:
OPERATOR => [:in, VALUE1, VALUE2, ...]
eg. :eq => [:in, 'open', 'in progress', 'coded']
also, the "Full property syntax" section (of CQL+Design) looks like http://sandwagn.wagn.org/wagn/multiple_values_in_property_and_operator_1 should return Lewis Hoffman *and* all cards with "John" in the name. I gather now that neither of these were implemented.
(In the future could we have a design section that only specifies the bits that have actually been implemented, or if not, use the language from whatever design to specify what's been implemented?) In this case, sounds like what was implemented was just "Short Property Syntax", up to "Note there's no need for", is that right?
Close, and ticket/idea implement in with operators, support full property syntax and support search on multiple values per relationship? (or maybe one Idea that we Ticket/split later?)
--John Abbe.....Fri Apr 17 17:48:46 -0700 2009
Oh, you're totally right on the operator front. I should have reviewed those designs before that comment. Yes, what you're saying about what has actually been done is right.
As for what to do with this ticket, I guess my inclination for the moment would be just to make sure the docs are ok and give it a more generic name. If we're clear that type is working, I think the piece that made it "high" priority can be put to rest. Medium or low is probably ok now, no?
--Ethan McCutchen.....Fri Apr 17 19:38:59 -0700 2009
Docs updated; after talking with Ethan, left the name but removed 0.13 and added a ticket for what's done - Support multiple values per property.
Is what's left of this a Connectipedia-requested thing?
--John Abbe.....Tue Apr 21 12:41:42 -0700 2009
I need to update docs, names, etc, but basically: all *relationships* now support multiple values.