- From: timeless <timeless@gmail.com>
- Date: Tue, 7 Jun 2011 19:16:48 -0400
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Israel Hilerio <israelh@microsoft.com>, Cameron McCormack <cam@mcc.id.au>, "public-webapps@w3.org" <public-webapps@w3.org>
On Tue, Jun 7, 2011 at 5:03 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> For example, say that we in version 2 of indexedDB add support for
> foreign keys. So that you can say:
>
> createObjectStore("car", { keyPath: "id", foreignKeys: [{keyPath:
> "brand", objectStore: "car-brands"}]);
> It seems bad that if a user thinking they are using a indexedDB
> implementation which supports version 2 calls this function and expect
> the foreignKey constraint enforced, but in reality they're calling it
> on a v1 implementation which silently ignores it.
would having a field: "mandatory" which indicates which arguments (or
feature names) must be supported by the implementation assuage your
concern?
createObjectStore("car", { mandatory: ["foreignKeys"], keyPath: "id",
foreignKeys: [{keyPath: "brand", objectStore: "car-brands"}]);
Received on Tuesday, 7 June 2011 23:17:15 UTC