RE: [IndexedDB] Multi-value keys

+1 on composite keys in general. The alternative to the proposal below would be to have the actual key path specification include multiple members (e.g. db.createObjectStore("foo", ["a", "b"])). I like the proposal below as well, I just wonder if having the key path specification (that's external to the object) indicate which members are keys would be less invasive for scenarios where you already have javascript objects you're getting from a web service or something and want to store them "as is". 

-pablo

From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org] On Behalf Of Jonas Sicking
Sent: Friday, June 18, 2010 4:08 PM

Hi All,

One thing that (if I'm reading the spec correctly) is currently impossible is to create multi-valued keys. Consider for example an object store containing objects like:

{ firstName: "Sven", lastName: "Svensson", age: 57 } { firstName: "Benny", lastName: "Andersson", age: 63 } { firstName: "Benny", lastName: "Bedrup", age: 9 }

It is easy to create an index which lets you quickly find everyone with a given firstName or a given lastName. However it doesn't seem possible to create an index that finds everyone with a given firstName
*and* lastName, or sort the list of people based on firstName and then lastName.

The best thing you could do is to concatenate the firstname and lastname and insert a ascii-null character in between and then use that as a key in the index. However this doesn't work if firstName or lastName can contain null characters. Also, if you want to be able to sort by firstName and then age there is no good way to put all the information into a single string while having sorting work.

Generally the way this is done in SQL is that you can create an index on multiple columns. That way each row has multiple values as the key, and sorting is first done on the first value, then the second, then the third etc.

However since we don't really have columns we can't use that exact solution. Instead, the way we could allow multiple values is to add an additional type as keys: Arrays.

That way you can use ["Sven",  57], ["Benny", 63] and ["Benny", 9] as keys for the respective objects above. This would allow sorting and searching on firstName and age.

The way that array keys would be compared is that we'd first compare the first item in both arrays. If they are different the arrays are ordered the same way as the two first-values are order. If they are the same you look at the second value and so on. If you reach the end of one array before finding a difference then that array is sorted before the other.

We'd also have to define the order if an array is compared to a non-array value. It doesn't really matter what we say here, but I propose that we put all array after all non-arrays.

Note that I don't think we need to allow arrays to contain arrays.
That just seems to add complication without adding additional functionality.

Let me know what you think.

/ Jonas

Received on Saturday, 19 June 2010 00:20:46 UTC