I'm currently building out the CouchDB API on top of IndexedDB and
achieving this particular use case is pretty trivial.
I would just process a map function like:
function (doc) { doc.names.forEach(function(n){emit(n, 1)})} ;
Then I would process that map function and create an index with each
On Fri, Jun 18, 2010 at 7:13 PM, Jeremy Orlow jor...@chromium.org wrote:
Another possible meaning for arrays is allowing someone to insert multiple
values into an index that point to one object store. For example:
{ names: [Sarah, Jessica, Parker], ...}
{ names: [Bono], ...}
{ names: [Jonas,
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,
The complex keys are how we do this in CouchDB as well. But, again,
the sorting algorithm needs to be well defined in order for it work.
http://wiki.apache.org/couchdb/View_collation#Collation_Specification
Most pertinent to your example is how arrays of varying length might
be ordered, for
On Fri, Jun 18, 2010 at 5:03 PM, Mikeal Rogers mikeal.rog...@gmail.com wrote:
The complex keys are how we do this in CouchDB as well. But, again,
the sorting algorithm needs to be well defined in order for it work.
http://wiki.apache.org/couchdb/View_collation#Collation_Specification
Most
+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
Reading back over my email is sounds opposing and that wasn't my
intention, it was a long way of saying +1 and giving an explanation
for why we went with the same approach in CouchDB.
-Mikeal
On Fri, Jun 18, 2010 at 5:06 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Jun 18, 2010 at 5:03 PM,
I didn't take it as opposing at all. I figured you'd like it as I
based it on your description of how you do it in CouchDB ;-)
I just wanted to make sure that we nail down all the details,
including the sorting order, so if you see anything wrong definitely
point it out!
/ Jonas
On Fri, Jun 18,
The biggest hole I see, even larger than sorting other types, is what
we use for string comparisons. In CouchDB we use the unicode collation
algorithm which is heavy but very well defined and works across
various localizations.
-Mikeal
On Fri, Jun 18, 2010 at 5:26 PM, Jonas Sicking
On Fri, Jun 18, 2010 at 5:18 PM, Pablo Castro
pablo.cas...@microsoft.com wrote:
+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
Yes, I think this is orthogonal to the issue of composite keys so I'd
rather deal with that in a separate thread.
/ Jonas
On Fri, Jun 18, 2010 at 5:30 PM, Mikeal Rogers mikeal.rog...@gmail.com wrote:
The biggest hole I see, even larger than sorting other types, is what
we use for string
I would like to see null and bool types in arrays as well.
null is useful if it is assured to sort before any other type, bool
types are useful if you want to use integers in the same sort as you
want bools and therefor could not just use 0 and 1 instead.
If you add all these new types (null,
On Friday, June 18, 2010, Mikeal Rogers mikeal.rog...@gmail.com wrote:
I would like to see null and bool types in arrays as well.
null is useful if it is assured to sort before any other type, bool
types are useful if you want to use integers in the same sort as you
want bools and therefor
Another possible meaning for arrays is allowing someone to insert multiple
values into an index that point to one object store. For example:
{ names: [Sarah, Jessica, Parker], ...}
{ names: [Bono], ...}
{ names: [Jonas, Sicking], ...}
Then I could look up Sicking inside an index with a keyPath
14 matches
Mail list logo
