Re: WebSimpleDB Issues

On Tue, Dec 1, 2009 at 10:33 PM, Kris Zyp <kris@sitepen.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I had few thoughts/questions/issues with the WebSimpleDB proposal:
>
> * No O(log n) access to position/counts in index sequences - If you
> want find all the entities that have a price less than 10, it is quite
> easy (assuming there is an index on that property) with the
> WebSimpleDB to access the price index, iterate through the index until
> you hit 10 (or vice versa). However, if this is a large set of data,
> the vast majority of applications I have built involve providing a
> subset or page of data at a time to keep constant or logarithmic time
> access to data, *and* an indication of how many rows/items/entities
> are available. Limiting a "query" to a certain number of items is easy
> enough with WebSimple, you just only iterate so far, but determining
> how many items are less than 10 is no longer a logarithmic complexity
> problem, but is linear with the number of items that are less 10,
> because you have to iterate over all of them to count them. If a
> cursor were to indicate the numeric position within an index (even if
> it was an estimate, without transactional strictness), one could
> easily determine the count of these type of queries in O(log n) time.
> This would presumably entail B-tree nodes keeping track of their
> number of children.
>
> * Asynchronicity is not well-aligned with the expensive operations -
> The asynchronous actions are starting and committing transactions. It
> makes sense that committing transactions would be expensive, but why
> do we make the start of a transaction asynchronous? Is there an
> expectation that the a global lock will be sought on the entire DB
> when the transaction is started? That certainly doesn't seem
> desirable. Normally a DB would create locks as data is accessed,
> correct? If anything a "get" operation would be more costly than
> starting a transaction.
>

I'm guessing the intention was to make very basic implementations of
concurrency practical.  At least I know this was also done by the SQL
Database spec for this reason and I know many elements of the Indexed
Database have borrowed from it.  In general I'd say this is a good thing
since it lowers the barrier to entry for implementors, but I agree that it
comes at a price for users.  Hm...


> * Hanging EntityStores off of transactions creates unnecessary
> complexity in referencing stores - A typical pattern in applications
> is to provide a reference to a store to a widget that will use it.
> However, with the WebSimpleDB, you can't really just hand off a
> reference to an EntityStore, since each store object is
> transaction-specific. You would either need to pass the name of store
> to a widget, and have it generate its own transaction to get a store
> (which seems like very bad form from object capability perspective),
> or pass in a store for every action, which may not be viable in many
> situations.
>
> Would it be reasonable (based on the last two points) to have
> getEntityStore be a method on database objects, rather than
> transaction objects? Actions would just take place in the current
> transaction for the context. With the single-threaded nature of JS
> contexts, having a single active transaction at a time doesn't not
> seem like a hardship, but rather makes things a lot simpler to work
> with. Also, if an impl wanted to support auto-commit, it would be very
> intuitive, devs just wouldn't be required to start a transaction prior
> performing actions on a store.
> Thanks,
>
> - --
> Kris Zyp
> SitePen
> (503) 806-1841
> http://sitepen.com
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAksWCkMACgkQ9VpNnHc4zAyheACfY53gDNjZ4gqud8rqCPANk+O7
> oJsAoIRaYfCjQK9gwaKCejPo76OBWbbE
> =Jcp0
> -----END PGP SIGNATURE-----
>
>
>