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

Tom Trenka ttrenka at gmail.com
Mon Aug 27 11:59:25 EDT 2007


If I may...I've only been following this conversation as a lurker, but I
will say that when I wrote the original collections.Store, I didn't force an
identity API on data at all...and I ended up with O(N^N) lookups.  When I
forced the user to have an identity (think that was between 0.4.0 and 0.4.1),
I was able to change that type of lookup to O(1), and it made a *huge*
difference in the performance of FilteringTable.
Though admittedly the majority of support questions I get revolve around
people forgetting to assign unique IDs.

I understand that there are some types of stores that don't need or want
some sort of unique ID assignment, but at the same time I think *anything*
that would help performance would be a plus; and frankly I don't see
anything wrong with Dijits needing an identity API in order to bind data
quickly and efficiently.

trt

On 8/27/07, Brian Douglas Skinner <skinner at dojotoolkit.org> wrote:
>
> 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
>
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at dojotoolkit.org
> http://dojotoolkit.org/mailman/listinfo/dojo-contributors
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20070827/6172b9df/attachment.htm 


More information about the dojo-contributors mailing list