On Tue, Mar 8, 2011 at 1:32 PM, Keean Schupke wrote:
> Actually I am not sure now if SQLite uses BDB now (they might be moving to
> it though). However BDB definitely now has an SQLite-3.0 compatible API now
> and supports better concurrency, as well as AES encryption. So at the moment
> looks li
Actually I am not sure now if SQLite uses BDB now (they might be moving to
it though). However BDB definitely now has an SQLite-3.0 compatible API now
and supports better concurrency, as well as AES encryption. So at the moment
looks like i'm moving to using BDB instead of SQLite, (apart from when
On Tue, Mar 8, 2011 at 1:33 AM, Joran Greef wrote:
> On 08 Mar 2011, at 7:23 AM, Dean Landolt wrote:
>
> > This doesn't seem right. Assuming your WebSQL implementation had all the
> same indexes isn't it doing pretty much the same things as using separate
> objectStores in IDB? Why would it be an
On 8 March 2011 06:33, Joran Greef wrote:
> On 08 Mar 2011, at 7:23 AM, Dean Landolt wrote:
>
> > This doesn't seem right. Assuming your WebSQL implementation had all the
> same indexes isn't it doing pretty much the same things as using separate
> objectStores in IDB? Why would it be an order of
On 08 Mar 2011, at 7:23 AM, Dean Landolt wrote:
> This doesn't seem right. Assuming your WebSQL implementation had all the same
> indexes isn't it doing pretty much the same things as using separate
> objectStores in IDB? Why would it be an order of magnitude slower? I'm sure
> whatever impleme
On Thu, Mar 3, 2011 at 4:15 AM, Joran Greef wrote:
> Hi Jonas
>
> I have been trying out your suggestion of using a separate object store to
> do manual indexing (and so support compound indexes or index object
> properties with arrays as values).
>
> There are some problems with this approach:
>
> On 05 Mar 2011, at 3:50 AM, Jonas Sicking wrote:
>
> What we do need to do sooner rather than later though is allowing
> multiple index values for a given entry using arrays. We also need to
> add support for compound keys. But lets deal with those issues in a
> separate thread.
Multiple index
Do you expect allowing multiple keys in a store to improve performance?
Presumably it will save space, but also make things slower due to needing to
reference count. Will we assume that two identical objects inserted with
different keys in different store commands are not referencing the same
objec
Like I said, I agree that we need to do something to allow for more
powerful indexes. We already have two options for allowing essentially
arbitrary indexes:
1. Use a separate objectStore which is manually managed.
2. Modify the object before inserting it to add a special property
which can then b
On 3 March 2011 09:15, Joran Greef wrote:
> Hi Jonas
>
> I have been trying out your suggestion of using a separate object store to
> do manual indexing (and so support compound indexes or index object
> properties with arrays as values).
>
> There are some problems with this approach:
>
> 1. It'
Hi Jonas
I have been trying out your suggestion of using a separate object store to do
manual indexing (and so support compound indexes or index object properties
with arrays as values).
There are some problems with this approach:
1. It's far too slow. To put an object and insert 50 index reco
On 2 March 2011 12:09, Joran Greef wrote:
> On 02 Mar 2011, at 1:31 PM, Jonas Sicking wrote:
>
> > I agree that we are currently enforcing a bit of schema due to the way
> > indexes work. However I think it's a good approach for an initial
> > version of this API as it covers the most simple use
On 02 Mar 2011, at 1:31 PM, Jonas Sicking wrote:
> I agree that we are currently enforcing a bit of schema due to the way
> indexes work. However I think it's a good approach for an initial
> version of this API as it covers the most simple use cases. Note that
> the more complex use cases are sti
On 2 March 2011 11:31, Jonas Sicking wrote:
> On Tue, Mar 1, 2011 at 10:35 PM, Joran Greef wrote:
> > On 01 Mar 2011, at 7:27 PM, Jeremy Orlow wrote:
> >
> >> 1. Be able to put an object and pass an array of index names which must
> reference the object. This may remove the need for a complicate
On Tue, Mar 1, 2011 at 10:35 PM, Joran Greef wrote:
> On 01 Mar 2011, at 7:27 PM, Jeremy Orlow wrote:
>
>> 1. Be able to put an object and pass an array of index names which must
>> reference the object. This may remove the need for a complicated indexing
>> spec (perhaps the reason why this iss
If you are operating on indexes then you do not have a 'join' language as
you are operating on sets. To have a join you need to be operating on
relations. A relation is commonly visualised as a row in a table in a
relational database, With IDB this would be the union of all the
property-sets of the
On 01 Mar 2011, at 7:27 PM, Jeremy Orlow wrote:
> 1. Be able to put an object and pass an array of index names which must
> reference the object. This may remove the need for a complicated indexing
> spec (perhaps the reason why this issue has been pushed into the future) and
> give developers
On Tue, Mar 1, 2011 at 7:34 AM, Joran Greef wrote:
> I have been following the development behind IndexedDB with interest. Thank
> you all for your efforts.
>
> I understand that the initial version of IndexedDB will not support
> indexing array values.
>
> May I suggest an alternative derived fr
I have been following the development behind IndexedDB with interest. Thank you
all for your efforts.
I understand that the initial version of IndexedDB will not support indexing
array values.
May I suggest an alternative derived from my home-brew server database evolved
from experience using
19 matches
Mail list logo
