[dojo-contributors] dijit.Tree assumes datastore implements Identity API

Brian Douglas Skinner skinner at dojotoolkit.org
Mon Aug 27 03:04:32 EDT 2007


Right, but the "Jane Smith" problem isn't a problem that we get stuck 
with as a result of the datastore offering a getIdentity() method.  The 
"Jane Smith" problem already exists, even if we don't offer a 
getIdentity() method.

If the server doesn't provide any sort of unique id's for us, and if the 
result sets of two different queries each include a "Jane Smith" record, 
then there's no reliable way for the datastore to know if the two "Jane 
Smith" results both represent the same Jane Smith, or if each represent 
a different Jane Smith.  In the result set for the second query, the 
datastore must either (a) include the exact same item that was used to 
represent "Jane Smith" in the first query result set, or (b) include a 
completely different item that represents this new different "Jane 
Smith".  Either way, the datastore could still offer a getIdentity() 
method that simply provides a unique identity for each unique item that 
is already getting created.  Offering getIdentity() doesn't make matters 
worse, and it should be easy to implement.

Anyway, I'm not actually trying to push for the Identity API to be 
required and be merged into the Read API.  Keeping it separate and 
optional seems okay too.  Just wanted to explore the idea.  Seemed like 
it might make life easier for widget authors.

:o) Brian



Jared Jurkiewicz wrote:
> Hence who Identity was optional in the first place.  for some 
> endpoint services, it may not simply be possible to generate a 
> proper identity that always referenced the same item from a 
> query, such as noted above.
> 
> Sincerely,
> -- Jared Jurkiewicz
> 
> 
> On 8/21/07, Brian Douglas Skinner <skinner at dojotoolkit.org> wrote:
>>>>> if you do some query like
>>>>>
>>>>> getData.php?attr1=foo
>>>>>
>>>>> and then it returns a list of item without id's, you're stuck.
>>>>> I'm not sure if that would ever happen in real life though?
>>>> I see.  Thanks for the explanation.
>>>>
>>>> Even in that case, couldn't the datastore still assign unique
>>>> id's to the items if it really wanted to?  The unique id could
>>>> be a compound key with two parts, like "xyz-267", where "xyz"
>>>> is a unique identifier for the query that was sent to the server,
>>>> and "267" is the index of the item in the result set returned
>>>> by the server?
>>> That's a bit too unique.  Two separate queries might return the
>>> same item but with different id's.
>> Right, but in that case there's really not much we can do.  If the
>> server doesn't provide any sort of unique id's for us, and if the result
>> sets of two different queries each include a "Jane Smith" record, then
>> there's no reliable way for us to know if the two "Jane Smith" results
>> both represent the same Jane Smith, or each represent a different Jane
>> Smith.  The server isn't giving us enough info here, so we have to do
>> the best with what we've got.
>>
>> :o) Brian
>>
>> _______________________________________________
>> dojo-contributors mailing list
>> dojo-contributors at dojotoolkit.org
>> http://dojotoolkit.org/mailman/listinfo/dojo-contributors
>>
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at dojotoolkit.org
> http://dojotoolkit.org/mailman/listinfo/dojo-contributors




More information about the dojo-contributors mailing list