Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#3207 closed enhancement (fixed)

[dojo.data] Identity API provides no way to find the identifying attribute, if it exists

Reported by: skinner Owned by: Jared Jurkiewicz
Priority: high Milestone:
Component: Data Version: 0.9
Keywords: Cc: Mignon Belongie <Mignon_Belongie@…>
Blocked By: Blocking:

Description

In dojo.data.api.Identity.js, we don't impose any requirement about whether or not the identity of an item is based on the item's attribute values. For example, a simple CsvStore? could provide a getIdentity implementation that returns the item's row number in the CSV file, even though "row number" is not an attribute of the item. A store connected to an SQL database might provide a getIdentity implementation that concatenates values from several primary key fields in a table.

In the case of dojo.data.JsonItemStore?, each item's identity is alway an attribute value. For example, here's a JsonItemStore? data file:

{ identifier: 'uid', 
  items: [
	{ uid:'943bb3', name:'Egypt',   capital:'Cairo' },
	{ uid:'45e7ba', name:'Ecuador', capital:'Quito' },
	{ uid:'c122a8', name:'Estonia', capital:'San Salvador' }
]}

Given a handle to the Egypt item, you can use the JsonItemStore? to find out a bunch of stuff. You can get the identity of the item ('943bb3'), and you can find out what attributes the item has ('uid', 'name', 'capital'), and you can find out the values of those attributes. But there's no reliable way to find out which of the attributes is being used as the identifier.

Practically speaking, that means there's no way to write UI code that treats the 'uid' attribute differently than other attributes. For example, in the OpenRecord? UI we want to hide the 'uid' attribute, so that the user only sees a table with columns for 'name' and 'capital'. Or in a different app you might want a UI where the 'uid' always shows up as the first column, or you might want the UI to treat the 'uid' as read-only even though all the other attributes are editable.

Unfortunately, I don't have a suggested fix for this problem. One possible solution is to add a new method to the Identity API: something like getIdentifierAttribute() or getIdentifierAttributes(). Another option would be to leave the Identity API as is, and instead change the Read API to explicitly say that the getAttributes() method should not include the identifier in the list of attributes, and then change the JsonItemStore? to conform to that new Read API requirement. Hopefully someone else will have an idea about what the right thing to do is.

Attachments (2)

dojo.data.JsonItemStore_IdentityUpdate_20070606.patch (3.0 KB) - added by Jared Jurkiewicz 12 years ago.
JsonItemStore? update and base API file update.
dojox.data.CsvStore_IdentityUpdate_20070606.patch (1.6 KB) - added by Jared Jurkiewicz 12 years ago.
JsonItemStore? update and base API file update.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 12 years ago by Jared Jurkiewicz

My vote would be to add it to the Identity API as a getIdentifierAttribute(). Specifying in Read that it doesn't show identity attributes then makes a 'circular' dependency between read and identity. I prefer APIs to be layered, not circular.

comment:2 Changed 12 years ago by Jared Jurkiewicz

Although I guess the argument could be made that an identifier is not generally a public attribute ... but then how do you go about setting it if it is not? Or are you always assuming the store itself would create the identity and it never be publically visible to users outside of getting its value?

comment:3 Changed 12 years ago by skinner

I think in some datastores the identifier will generally be public, while in other datastores the identifier will not be public. And in some cases the datastore will automatically create a new identity for each new item, and in other cases the datastore will require that a new identity must be provided to the datastore when a new item is created.

The solution jaredj proposed sounds good to me: we don't put any constraints on the Read API (and thus avoid 'circular' API references), and in the Identity API we add a new getIdentifierAttribute() method. The getIdentifierAttribute() method may return null if the datastore does not expose a public attribute for the identifier (for example, for a CsvStore? that uses the row number as the identity). And for an RDBMS datastore with a compound key, I guess getIdentifierAttribute() could return an array of attributes.

comment:4 Changed 12 years ago by Jared Jurkiewicz

Type: defectenhancement

comment:5 Changed 12 years ago by Jared Jurkiewicz

Dojo meeting at: http://dojotoolkit.org/book/developers-notebook/data-access-meetings/data-access-meeting-2007-06-05

Finds closure on this topic. API will be updated with descisions this week.

Changed 12 years ago by Jared Jurkiewicz

JsonItemStore? update and base API file update.

Changed 12 years ago by Jared Jurkiewicz

JsonItemStore? update and base API file update.

comment:6 Changed 12 years ago by Jared Jurkiewicz

(In [8938]) Checking in minor API addition. refs #3207

comment:7 Changed 12 years ago by Jared Jurkiewicz

Resolution: fixed
Status: newclosed

(In [8939]) Checking in minor API addition. fixes #3207

comment:8 Changed 12 years ago by Jared Jurkiewicz

Tested on:

Windows:

Firefox 2.0.0.4 Seamonkey 1.1.1 IE 6 Opera 9.2

Note: See TracTickets for help on using tickets.