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"}]);