Re: [IndexedDB] Compound and multiple keys
I think I prefer A. Declaring the keys in advance is stating to sound a
little like a schema, and when you go down that route you end up at SQL
schemas (which is a good thing in my opinion). I understand however that
some people are not so comfortable with the idea of a schema, and these
people seem to be the kind of people that like IndexedDB. So, although I
prefer A for me, I would have to say B for IndexedDB.
So in conclusion: I think "B" is the better choice for IndexedDB, as it is
more consistent with the design of IDB.
As for the cons of "B", sorting an array is just like sorting a string, and
it already supports string types.
Surely there is also option "C":
store.add({firstName: "Benny", lastName: "Zysk", age: 28}, ["firstName",
"lastName"]);
store.add({firstName: "Benny", lastName: "Andersson", age:
63}, ["firstName", "lastName"]);
Like "A", but listing the properties to include in the composite index with
each add, therefore avoiding the "schema"...
As for layering the Relational API over the top, It doesn't make any
difference, but I would prefer whichever has the best performance.
Cheers,
Keean.
On 2 December 2010 00:57, Jonas Sicking wrote:
> Hi IndexedDB fans (yay!!),
>
> Problem description:
>
> One of the current shortcomings of IndexedDB is that it doesn't
> support compound indexes. I.e. indexing on more than one value. For
> example it's impossible to index on, and therefor efficiently search
> for, firstname and lastname in an objectStore which stores people. Or
> index on to-address and date sent in an objectStore holding emails.
>
> The way this is traditionally done is that multiple values are used as
> key for each individual entry in an index or objectStore. For example
> the CREATE INDEX statement in SQL can list multiple columns, and
> CREATE TABLE statment can list several columns as PRIMARY KEY.
>
> There have been a couple of suggestions how to do this in IndexedDB
>
> Option A)
> When specifying a key path in createObjectStore and createIndex, allow
> an array of key-paths to be specified. Such as
>
> store = db.createObjectStore("mystore", ["firstName", "lastName"]);
> store.add({firstName: "Benny", lastName: "Zysk", age: 28});
> store.add({firstName: "Benny", lastName: "Andersson", age: 63});
> store.add({firstName: "Charlie", lastName: "Brown", age: 8});
>
> The records are stored in the following order
> "Benny", "Andersson"
> "Benny", "Zysk"
> "Charlie", "Brown"
>
> Similarly, createIndex accepts the same syntax:
> store.createIndex("myindex", ["lastName", "age"]);
>
> Option B)
> Allowing arrays as an additional data type for keys.
> store = db.createObjectStore("mystore", "fullName");
> store.add({fullName: ["Benny", "Zysk"], age: 28});
> store.add({fullName: ["Benny", "Andersson"], age: 63});
> store.add({fullName: ["Charlie", "Brown"], age: 8});
>
> Also allows out-of-line keys using:
> store = db.createObjectStore("mystore");
> store.add({age: 28}, ["Benny", "Zysk"]);
> store.add({age: 63}, ["Benny", "Andersson"]);
> store.add({age: 8}, ["Charlie", "Brown"]);
>
> (the sort order here is the same as in option A).
>
> Similarly, if an index pointed used a keyPath which points to an
> array, this would create an entry in the index which used a compound
> key consisting of the values in the array.
>
> There are of course advantages and disadvantages with both options.
>
> Option A advantages:
> * Ensures that at objectStore/index creation time the number of keys
> are known. This allows the implementation to create and optimize the
> index using this information. This is especially useful in situations
> when the indexedDB implementation is backed by a SQL database which
> uses columns as a way to represent multiple keys.
> * Easy to use when key values appear as separate properties on the
> stored object.
> * Obvious how to sort entries.
>
> Option A disadvantages:
> * Doesn't allow compound out-of-line keys.
> * Requires multiple properties to be added to stored objects if the
> components of the key isn't available there (for example if it's
> out-of-line or stored in an array).
>
> Option B advantages:
> * Allows compound out-of-line keys.
> * Easy to use when the key values are handled as an array by other
> code. Both when using in-line and out-of-line keys.
> * Maximum flexibility since you can combine single-value keys and
> compound keys in one objectStore, as well as arrays of different
> length (we couldn't come up with use cases for this though).
>
> Option B disadvantages:
> * Requires defining sorting between single values and arrays, as well
> as between arrays of different length.
> * Requires a single property to be added to stored objects if the key
> isn't available there (for example if it's stored as separate
> properties).
>
> There is of course a third alternative: Do both Option A and Option B.
> This brings most of the advantages of both options, but also many of
> the disadvantages of both. It also adds a lot of API surface which
>
Issue in DIgital Signature test suite
All I have created a test case using the script provided in the w3c test-suite. The test case is created successfully. But when I tried to validate the created widget using the validate script, the signature does not get validated. 1)Test- Case creation: -- $ ./create-test-case.sh ta-99 99a * Creating /home/BORQSADC/rajshekark/w3c_testsuite/2006/waf/widgets-digsig/test-suite/test-cases/ta-99 ... * Copying template to /home/BORQSADC/rajshekark/w3c_testsuite/2006/waf/widgets-digsig/test-suite/test-cases/ta-99/99a ... * Adding correct IDs to files... * Generating signatures Key type rsa Widget is a directory Signed author-signature.xml Signed /home/BORQSADC/rajshekark/w3c_testsuite/2006/waf/widgets-digsig/test-suite/test-cases/ta-99/99a Key type rsa Widget is a directory Signed signature1.xml Signed /home/BORQSADC/rajshekark/w3c_testsuite/2006/waf/widgets-digsig/test-suite/test-cases/ta-99/99a Key type rsa Widget is a directory Signed signature2.xml Validating... SUCCESS Signed /home/BORQSADC/rajshekark/w3c_testsuite/2006/waf/widgets-digsig/test-suite/test-cases/ta-99/99a * Zipping widget... adding: CVS/ (stored 0%) adding: LICENSE (deflated 7%) adding: author-signature.xml (deflated 45%) adding: config.xml (deflated 25%) adding: index.html (deflated 33%) adding: signature1.xml (deflated 47%) adding: signature2.xml (deflated 60%) /home/BORQSADC/rajshekark/w3c_testsuite/2006/waf/widgets-digsig/test-suite/tools * Adding test to test-suite.xml... Done. -- 2) Test-case Validation -- $ ./validate-widget.sh --trusted-pem /home/BORQSADC/rajshekark/w3c_testsuite/2006/waf/widgets-digsig/test-suite/keys/root.cert.pem /home/BORQSADC/rajshekark/w3c_testsuite/2006/waf/widgets-digsig/test-suite/test-cases/ta-99/99a/99a.wgt Working in /tmp/.15779 ./author-signature.xml Signature method RSA if xmlsec1 verify --trusted-pem /home/BORQSADC/rajshekark/w3c_testsuite/2006/waf/widgets-digsig/test-suite/keys/root.cert.pem ./author-signature.xml func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=360:obj=x509-store:subj=X509_verify_cert:error=4:crypto library function failed:subj=/C=NO/ST=Oslo/O=World Wide Web Consortium/OU=w3c-widgets-digsig-testsuite sig and encryption certificate/CN=http://www.w3.org//emailaddress=stua...@opera.com;err=20;msg=unable to get local issuer certificate func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=408:obj=x509-store:subj=unknown:error=71:certificate verification failed:err=20;msg=unable to get local issuer certificate func=xmlSecKeysMngrGetKey:file=keys.c:line=1370:obj=unknown:subj=xmlSecKeysMngrFindKey:error=1:xmlsec library function failed: func=xmlSecDSigCtxProcessKeyInfoNode:file=xmldsig.c:line=871:obj=unknown:subj=unknown:error=45:key is not found: func=xmlSecDSigCtxProcessSignatureNode:file=xmldsig.c:line=565:obj=unknown:subj=xmlSecDSigCtxProcessKeyInfoNode:error=1:xmlsec library function failed: func=xmlSecDSigCtxVerify:file=xmldsig.c:line=366:obj=unknown:subj=xmlSecDSigCtxSigantureProcessNode:error=1:xmlsec library function failed: Error: signature failed ERROR SignedInfo References (ok/all): 4/4 Manifests References (ok/all): 0/0 Error: failed to verify file "./author-signature.xml" INVALID SIGNATURE: ./author-signature.xml ./signature1.xml Signature method RSA if xmlsec1 verify --trusted-pem /home/BORQSADC/rajshekark/w3c_testsuite/2006/waf/widgets-digsig/test-suite/keys/root.cert.pem ./signature1.xml func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=360:obj=x509-store:subj=X509_verify_cert:error=4:crypto library function failed:subj=/C=NO/ST=Oslo/O=World Wide Web Consortium/OU=w3c-widgets-digsig-testsuite sig and encryption certificate/CN=http://www.w3.org//emailaddress=stua...@opera.com;err=20;msg=unable to get local issuer certificate func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=408:obj=x509-store:subj=unknown:error=71:certificate verification failed:err=20;msg=unable to get local issuer certificate func=xmlSecKeysMngrGetKey:file=keys.c:line=1370:obj=unknown:subj=xmlSecKeysMngrFindKey:error=1:xmlsec library function failed: func=xmlSecDSigCtxProcessKeyInfoNode:file=xmldsig.c:line=871:obj=unknown:subj=unknown:error=45:key is not found: func=xmlSecDSigCtxProcessSignatureNode:file=xmldsig.c:line=565:obj=unknown:subj=xmlSecDSigCtxProcessKeyInfoNode:error=1:xmlsec library function failed: func=xmlSecDSigCtxVerify:file=xmldsig.c:line=366:obj=unknown:subj=xmlSecDSigCtxSigantureProcessNode:error=1:xmlsec library function failed: Error: signature failed ERROR SignedInfo References (ok/all): 5/5 Manifests References (ok/all): 0/0 Error: failed to verify file "./signature1.xml" INVALID SIGNATURE: ./signature1.xml ./signature2.xml Signature method RSA if xmlsec1 verify --trusted-pem /home/BORQSADC/raj
Re: [IndexedDB] Compound and multiple keys
Disclaimer: all of my db experience is with SQL. I prefer option A. It's simple and easy. Option B requires you to potentially duplicate information into an array to use as a key, which I don't like. That said, I don't have much experience with out-of-line keys. Can we combine A & B such that in-line keys are A and out-of-line keys are B? That seems to be intuitive. To answer your specific questions, I've never used a compound key with variably numbers of columns. (Disclaimer: I'm strongly in the synthetic-key camp, so I don't really use compound keys anyway. But I've never seen an instance where I would have wanted to use a variable number of columns, were I to index the table with a compound key.) I can't distinguish your second question from the first. For your third question, the closest analogue in SQL to an array is a SET. I can't tell whether or not SETs can be used as keys. ~TJ
[IndexedDB] Compound and multiple keys
Hi IndexedDB fans (yay!!),
Problem description:
One of the current shortcomings of IndexedDB is that it doesn't
support compound indexes. I.e. indexing on more than one value. For
example it's impossible to index on, and therefor efficiently search
for, firstname and lastname in an objectStore which stores people. Or
index on to-address and date sent in an objectStore holding emails.
The way this is traditionally done is that multiple values are used as
key for each individual entry in an index or objectStore. For example
the CREATE INDEX statement in SQL can list multiple columns, and
CREATE TABLE statment can list several columns as PRIMARY KEY.
There have been a couple of suggestions how to do this in IndexedDB
Option A)
When specifying a key path in createObjectStore and createIndex, allow
an array of key-paths to be specified. Such as
store = db.createObjectStore("mystore", ["firstName", "lastName"]);
store.add({firstName: "Benny", lastName: "Zysk", age: 28});
store.add({firstName: "Benny", lastName: "Andersson", age: 63});
store.add({firstName: "Charlie", lastName: "Brown", age: 8});
The records are stored in the following order
"Benny", "Andersson"
"Benny", "Zysk"
"Charlie", "Brown"
Similarly, createIndex accepts the same syntax:
store.createIndex("myindex", ["lastName", "age"]);
Option B)
Allowing arrays as an additional data type for keys.
store = db.createObjectStore("mystore", "fullName");
store.add({fullName: ["Benny", "Zysk"], age: 28});
store.add({fullName: ["Benny", "Andersson"], age: 63});
store.add({fullName: ["Charlie", "Brown"], age: 8});
Also allows out-of-line keys using:
store = db.createObjectStore("mystore");
store.add({age: 28}, ["Benny", "Zysk"]);
store.add({age: 63}, ["Benny", "Andersson"]);
store.add({age: 8}, ["Charlie", "Brown"]);
(the sort order here is the same as in option A).
Similarly, if an index pointed used a keyPath which points to an
array, this would create an entry in the index which used a compound
key consisting of the values in the array.
There are of course advantages and disadvantages with both options.
Option A advantages:
* Ensures that at objectStore/index creation time the number of keys
are known. This allows the implementation to create and optimize the
index using this information. This is especially useful in situations
when the indexedDB implementation is backed by a SQL database which
uses columns as a way to represent multiple keys.
* Easy to use when key values appear as separate properties on the
stored object.
* Obvious how to sort entries.
Option A disadvantages:
* Doesn't allow compound out-of-line keys.
* Requires multiple properties to be added to stored objects if the
components of the key isn't available there (for example if it's
out-of-line or stored in an array).
Option B advantages:
* Allows compound out-of-line keys.
* Easy to use when the key values are handled as an array by other
code. Both when using in-line and out-of-line keys.
* Maximum flexibility since you can combine single-value keys and
compound keys in one objectStore, as well as arrays of different
length (we couldn't come up with use cases for this though).
Option B disadvantages:
* Requires defining sorting between single values and arrays, as well
as between arrays of different length.
* Requires a single property to be added to stored objects if the key
isn't available there (for example if it's stored as separate
properties).
There is of course a third alternative: Do both Option A and Option B.
This brings most of the advantages of both options, but also many of
the disadvantages of both. It also adds a lot of API surface which
could conflict with future features, so it's something I'd really like
to avoid.
Questions:
The main question we had if there is a use case for having different
number of compound-key-values for the entries in a index or
objectStore? I.e. is there a case when you, in one objectStore, want
to have one record with a compound key consisting of 2 different
values, and another record consisting of 3, 4 or 5?
In all the cases where I've used compound keys, each key-part has been
vital. For example a table storing sale totals by quarter, country and
price class. In this case it's obviously always going to be 3 parts to
the compound key. Does anyone have counter examples?
Similarly, are there use cases which require compound keys that
doesn't have a hard limit on the number of values? I.e. where you
could find out more and more detail about an item and describe that by
adding additional values to the key.
Another question is if there are databases out there which allow using
arrays as keys, similar to option B above. It seems particularly
likely to find "NoSQL" databases that uses this. None of the SQL
databases we looked at allowed keying off of arrays, which isn't
terribly surprising since SQL databases tend to create compound keys
using separate columns, rather than multiple values in a single
column.
Suggested solutions:
[widgets] WARP test bugs
# hg (download, files) Tests that the UA processes an access element with a valid origin. To pass, the access list must contain a single entry where the scheme is "http", the host is "w3.org", the port is "80", and subdomains is "false". The origin contains a trailing slash, which is treated as path information and hence the origin is treated as being invalid: http://w3.org/"/> # la (download, files) Tests that the UA processes access elements using the ToASCII algorithm. To pass, the access list must contain one entry where the scheme is "http", the host is "xn--xkry9kk1bz66a.cn", the port is "80", and subdomains is "true". Unless I'm missing something here there are actually two valid access elements in the widget, not one: http://हिन्दी.idn.icann.org"/> http://उदाहरण.परीक्षा"; subdomains="true"/> # ma (download, files) Tests that the UA processes multiple access elements. To pass, the access list must contain two entries; one where the scheme is "http", the host is "w3.org", the port is "80", and subdomains is "true", one where the scheme is "http", the host is "pass", the port is null, and subdomains is "false". The order of the entries is not important. The second element contains "ietf.org" not "pass". smime.p7s Description: S/MIME cryptographic signature
[widgets] test "viewh" in error
# viewh (download, files) Test the UA's ability process a viewmodes attribute containing supported and unsupported values. To pass, the viewmodes list should be "windowed maximized" if the UA supports all of these. The widget itself contains viewmodes="windowed not-supported floating" - so a correct answer would be "windowed floating". smime.p7s Description: S/MIME cryptographic signature
[widgets] test "bn" in error
# bn (download, files) Tests the UA's ability to deal with custom icon declarations in the config document and matching default icons. To pass, the icons list must contain a pointer to "icons/pass.png", and "locales/en/icon.jpg" (ordering of the items in the list is irrelevant). The actual icons included are "icons/pass.png" and "locales/en/icon.png" (not .jpg). smime.p7s Description: S/MIME cryptographic signature
[widgets] Error in test case "bm"
# bm (download, files) Tests the UA's ability to deal with custom icon declaration in the config document and matching default icons. To pass, the icons list must contain a pointer to "locales/en/icon.jpg", and "icon.png", which is at the root of the widget. The icons list can be in any order, so long as it contains "icon.png" and "locales/en/icon.jpg". The download contains two icons, but one of these is called "333icon.png" and so would be ignored. smime.p7s Description: S/MIME cryptographic signature
[widgets] missing tests?
Tests bd,be,bf for assertion ta-DwhJBIJRQN seem to have gone - have these been removed from the test suite or been renamed? smime.p7s Description: S/MIME cryptographic signature
[widgets] test "dl" is in error
# dl (download, files) Expected: invalid Test the ability of the UA to verify a zip archive. To pass, the user agent must treat this as an invalid widget (archive is encrypted - password is test). The download is just a regular zip archive and isn't encrypted. smime.p7s Description: S/MIME cryptographic signature
