Support multiple values per key



Because both the JSON and the ruby representation of WQL are hashes, we can't do multiple keys. This ends up limiting WQL in some important ways. We've implemented part of this ticket, so that you can write WQL to find all the cards that are either Cities or States.


But you can't yet find cards with "Katrina" or "Joseph" somewhere in the name, or are either tagged with "wiki" or have an image plussed to them.


We've outlined our current solutions here:



The most important ones now are the rest of the simple property/operator syntax and the plus cards.


Some of that might not make a ton of sense if you haven't gotten your head around CQL Syntax.


We'll be implementing this over more than one release. For Wagn 0.13, we implemented Support multiple values per property, e.g.:

{"type": ["in", "User", "Company"] }


Here's one search that should work once we support multiple values.


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


  --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 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.

--Ethan McCutchen.....2013-11-06 17:37:28 +0000