[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
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.
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.
> -- Jared Jurkiewicz
> On 8/21/07, Brian Douglas Skinner <skinner at dojotoolkit.org> wrote:
>>>>> if you do some query like
>>>>> 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
> dojo-contributors mailing list
> dojo-contributors at dojotoolkit.org
More information about the dojo-contributors