[Developers] State Quarters example and "need a unique result to attach here"

[David Flanagan]

Christopher R. Maden wrote:
> David Flanagan wrote:
>> I understand that, but in this case (and as you point out), a US state 
>> is uniquely identified by its name and its type.  I'm wondering why, 
>> therefore, the expected type of the state property plus the name of the 
>> state isn't sufficient to identify the state object I want.  (And why is 
>> it confused about a city named Delaware?)
>>
>> In order to make my documentation clear, I need to understand not just 
>> why it is a bad idea, but why it doesn't work!
> 
> I will let one of the developers handle the rationale.
> 
> But we are not yet at a point where we can generally assume that things 
> are well-enough typed to use as a filter programmatically, so when you 
> specify something solely by name in MQL, it filters solely on the name. 
>   If you want to filter on name and type, you must specify the name and 
> type.

I don't understand what you're saying here.

Surely when I specify a name as the value of a property, the match is 
done using the expected type of the property as well as the name value 
I've specified.

To tie this to the state quarters example, now that I've created an 
object to represent the Delaware state quarter, I can write a read query 
like this:

  {
     "type": "/user/docs/default_domain/us_state_quarter",
     "state":"Delaware",
     "mintage":null
   }

This query works.  Here I can identify the US State of Delaware by name.

But I can't do the same in a write query.  This query fails:

  {
     "create":"unless_exists",
     "type": "/user/docs/default_domain/us_state_quarter",
     "state":"Washington"
   }

It fails because it can find more than one object with name 
"Washington", even though only one of those objects is a possible value 
of the state property.

The other curious thing that I found is that the problem goes away if 
the state quarter object already exists--in that case it doesn't have 
problems with too many matches.  So I'm wondering if the behavior I'm 
seeing has to do with the fact that the Washington state quarter doesn't 
exist.  Since there is no state quarter instance to have a state 
property, maybe it doesn't look at the expected type of that property?


	David

> 
> It is also worth noting that, as per Bryan Cheung’s post to the data 
> modeling list, cities and towns are now given their simple names 
> (“Delaware”) rather than their formerly disambiguated names (“Delaware, 
> Ohio”).
> 
> ~Chris