in any case where we're currently searching for exact matches on name, we should be searching on the key.
I'd actually like to do this on types, too. The easiest way to do this would probably be to make type into a relationship, not a property, which would open up a lot of possibilities, like:
But I don't think Lew is sold on this yet, because it will make the SQL nastier unless we optimize.
I think this is now the case on everything, including types. I found a simpler way to achieve that. (but I still want to do the relationship thing. I may have ideas about easy ways to optimize).
--Ethan McCutchen.....Wed Mar 18 18:13:17 -0700 2009
Would you ticket that, Ethan? I'm not sure what to name it, nor how to describe it.
--John Abbe.....Thu Apr 09 15:53:59 -0700 2009
Not working in all cases; see http://sandwagn.indecks.net/wagn/wql_testing
--John Abbe.....Thu Apr 09 16:02:28 -0700 2009
good catch. explicit 'name' searches don't do fuzzy. I figure they should. let's move this to 1.0 (the hard stuff is all done)
--Ethan McCutchen.....Thu Apr 09 17:05:29 -0700 2009
Looks to me like the type query is working now, as I would have expected. After looking at the code, I'm not surprised the explicit name search doesn't work, since explicit property/operators generally get passed through pretty literally.
As a design consideration, it feels right to plan to support fuzzy names even in those explicit cases, but in practice the issue is way less pressing now. I'd say at least 98% of the time we mention names in searches it's either (a) as a simple card def, as in a relationship, or (b) as a type value. Both of those cases now work, so I'm going to reduce this to "low" priority and make the name narrower.
--Ethan McCutchen.....Sun Apr 26 21:09:50 -0700 2009