On Tue, Jun 7, 2011 at 5:03 PM, Jonas Sicking <jo...@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"}]);

Reply via email to