On Fri, Jun 18, 2010 at 7:13 PM, Jeremy Orlow 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", "Sic
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
k
On Fri, Jun 18, 2010 at 7:24 PM, Jonas Sicking wrote:
> On Fri, Jun 18, 2010 at 7:01 PM, Jeremy Orlow wrote:
> > I think determinism is most important for the reasons you cited. I think
> > advanced, performance concerned apps could deal with either semantics you
> > mentioned, so the key would
On Thu, Jun 17, 2010 at 3:25 PM, Jonas Sicking wrote:
> Hi All,
>
> We've debated a bit use cases like storing objects like:
>
> { name: "Elvis", born: "January 8, 1935", died: "August 16, 1977" }
> { name: "Gustav III", born: "24 January 1746", died: "29 March 1792" }
>
> And create an index bas
On Fri, Jun 18, 2010 at 7:01 PM, Jeremy Orlow wrote:
> I think determinism is most important for the reasons you cited. I think
> advanced, performance concerned apps could deal with either semantics you
> mentioned, so the key would be to pick whatever is best for the normal case.
> I'm leaning
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 wi
I think determinism is most important for the reasons you cited. I think
advanced, performance concerned apps could deal with either semantics you
mentioned, so the key would be to pick whatever is best for the normal case.
I'm leaning towards thinking firing in order is the best way to go becaus
On Friday, June 18, 2010, Mikeal Rogers 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 could not just use 0
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, boo
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 wrote:
> The biggest hole I see, even larger than sorting other types, is what
> we use for string comparisons. In CouchDB we u
On Fri, Jun 18, 2010 at 5:18 PM, Pablo Castro
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 below as well,
> I ju
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 wrote:
> I di
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,
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 wrote:
> On Fri, Jun 18, 2010 at 5:03 PM, Mikeal Rogers
+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 externa
On Fri, Jun 18, 2010 at 5:03 PM, Mikeal Rogers 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 pertinent to your ex
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 insta
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:
Hi All,
One thing that we've talked a bit about at mozilla is about in which
order asynchronous events should fire. I.e. for code like:
results = [];
trans = db.transaction(["mystore"]);
trans.objectStore("mystore").get(1).onsuccess = function(e) {
results.push(e.result);
}
trans.objectStore("m
Eric,
Based upon your responses there are a couple of additional things we
need to check on, but I'll look deeper into the current specs for the
things that should already be supported.
The additional things are:
- how to safely grant access "outside the sandbox", which depends upon
ability to di
Hi Christoph,
On 17 Jun 2010, at 14:26, Christoph Storm wrote:
> Hi,
> I am currently very busy reading your papers about W3C Widgets because I am
> writing my master thesis about Widgets. The title is "Device interoperable
> data visualization using standard W3C Widgets" - the important word i
21 matches
Mail list logo
