Re: indexeddb and object store events

I have read this complains to the API before and I have to admit that
it doesn't seems difficult to me too, but the fact is that I'm
studying a computers degree and also have worked before with AppEngine
storage... :-P But I must to admit that the IndexedDB primitives are
"too primitives" and would be nice to have more syntactic sugar and
more high level functionality, like full-text search or object
references or specially CRUD events. A query language like GQL would
be also nice, and I think that the most of the complainst against
IndexedDB are related to this topic, too much people is used to SQL
and not so much to NoSQL and key-value object stores...


2013/2/17 Miko Nieminen <miko.nieminen@iki.fi>:
> Asking my previous question again.
>
> There has been some discussions in www-tag list about IndexedDB API as an
> addition to discussion happening here. At www-tag, I was instructed to
> return back to this list with my question.
>
> There seems to be worry over IDB that it is too low level API and too
> complicated or verbose to use by someone not having degree in computer
> science. I do understand this worry, but at the same time I haven't seen any
> proper suggestions for better API than what we have and to be honest I'm
> quite happy with the current API. I don't feel it is too verbose especially
> when I see that the verbosity improves readability in this case. Only part
> that I feel could possibly be simplified is the use of transactions. Though
> I don't see any other solution for this than auto transactions and that kind
> of mechanism would probably have its own issues and would complicate
> implementation of IDB and I definitely don't want to see transactions going
> away. Other than that, I don't really think that the API requires much more
> simplifications and if it does, I don't really know how to do that. I think
> slightly harder lower level API at this point is much better than over
> simplified higher level API that limits use of too much. On top of lower
> level API you can write generic abstraction layers in Javascript, but not
> other way around. In the future version of the API we can then go back and
> see what kind of issues different abstractions are trying to solve and then
> add needed parts in the standard.
>
> But to the actual topic. As I raised earlier, main true problem with IDB is
> that I cannot listen changes in a object store. This does not feel that
> important when coming from SQL world, but after using other NoSQL databases
> and especially when thinking about rest of the web APIs, it doesn't make
> much sense not to have these events. WebStorage API defines this kind of
> mechanism and I feel it is quite odd that IDB does not.
>
> I have three quite clear use cases for this one that could be much
> simplified with these events:
> 1) I want to create synchronization library that is generic component
> providing IDB client to server sync. For example I have REST API for data in
> my service and I want to keep my clients in sync with the sevice over web
> sockets. To create this I need to wrap local modification requests to notify
> my library about the changes. In other words, I need to make my other
> components to know about this sync components, instead just including the
> component and telling which object stores to keep in sync and then this
> component could listen for new objects, modifications and deleted objects
> and notify service about these changes or it could just modify database when
> service notifies of change and my application component would see
> modification through object store events.
> 2) I want to create search component for so that I can index all words found
> in my objects. For example I create notes app where I want to index all
> words found in all notes and map those to my note objects. Then I want to
> use key range search for searching all notes that have words starting with
> my search term. This is a bit naïve example and it can be implemented by
> adding the code into my modification places, but again I would like to have
> generic component that does the indexing by listening these changes and then
> just include this library in my app.
> 3) I want to keep multiple windows in sync with changes in my objects. There
> are lots of approaches to have this, by using local storage as communication
> channel or create postMessage channel, but this is all just additional code
> that should not be needed in the first place and I need to hook my code that
> makes modifications to make these notifications instead just listening
> changes in my object store and hooking my HTML updates to these change
> events.
>
> To simplify implementation of these example cases, I would like to listen
> change events through object store so that I know when object is added,
> modified or deleted. I think these events should be launched right after
> transaction is completed. This raises some questions that how about order of
> these events or should we provide some kind of change chunk mechanism like
> for example CouchDB has when listening change notifications. At the first
> version, I wouldn't solve these issues. It should not matter in which order
> these events come as long as mid transaction changes are not notified. Add +
> put should be notiified as add, put + delete should be notified as delete,
> and multiple puts should be notified as single put showing the last state.
> Should we have multiple objects in one change, is a good question.
>
> So far I haven't got other feedback than this is fairly good idea and
> probably should be included in the official API, but is it stillpossible to
> get this kind of changes included in the API or am I too late with this
> request? If it is possible to have this change, is there anything I can do
> to help it getting forward? I'm working on reference implementation in
> Mozilla's codebase and I feel I'm quite close getting the first version
> working, but I'm hacking it on my free time and I have no previous
> experience from Mozilla's code so the progress is somewhat slow.
>
> --
> Miko Nieminen
> miko.nieminen@iki.fi
> miko.nieminen@gmail.com
>



-- 
"Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton de sitios diferentes, simplemente escribe un sistema operativo
Unix."
– Linus Tordvals, creador del sistema operativo Linux

Received on Sunday, 17 February 2013 17:18:55 UTC