[dojo-contributors] dijit.Tree assumes datastore implements Identity API
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.
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
> >> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dojo-contributors