Re: Persistent Storage vs. Database

On Fri, Mar 8, 2013 at 8:16 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Fri, Mar 8, 2013 at 2:27 PM, Andrew Fedoniouk
> <news@terrainformatica.com> wrote:
>> On Fri, Mar 8, 2013 at 11:30 AM, Kyle Huey <me@kylehuey.com> wrote:
>>> On Fri, Mar 8, 2013 at 11:02 AM, Andrew Fedoniouk
>>> <news@terrainformatica.com> wrote:
>>>>
>>>> On Thu, Mar 7, 2013 at 10:36 PM, Kyle Huey <me@kylehuey.com> wrote:
>>>> > On Thu, Mar 7, 2013 at 10:20 PM, Andrew Fedoniouk
>>>> > <news@terrainformatica.com> wrote:
>>>> >
>>>> >> At least it is easier than http://www.w3.org/TR/IndexedDB/ :)
>>>> >
>>>> >
>>>> > Easier doesn't necessarily mean better.  LocalStorage is certainly
>>>> > easier to
>>>> > use than any async storage system ;-)
>>>> >
>>>>
>>>> At least my implementation does not use any events. Proposed
>>>> system of events in IndexedDB is the antipattern indeed. Exactly for
>>>> the same reasons as finalizer *events* you've mentioned above - there
>>>> is no guarantee that all events will be delivered to the code awaiting
>>>> and relaying on them.
>>>
>>>
>>> That's not true at all.  If you don't understand the difference between
>>> finalizers and events you're not going to be able to make a very informed
>>> criticism of IndexedDB.
>>>
>>
>> I would appreciate if you will define term `event`. After that we can discuss
>> it further.
>
> https://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#interface-event

Thanks, but these are DOM events. How they are related to DB events or
whatever they are named?  What does it mean bubbling/capturing for them?


>
>> As of common practice there are two types so called outbound calls:
>> 1. Synchronous *callbacks* that are not strictly speaking events - just function
>>    references: "after/before-doing-this-call-that". 'finalized' is
>> that kind of callback.
>> 2. Events - these are objects and event dispatching system associated
>>    with them. For example UI events use capture/bubble dispatching
>>    system and event queue. Events operate independently from their
>>    handlers.
>>
>> Let's take a look on this example from IndexedDB spec:
>>
>> var request = indexedDB.open('AddressBook', 15);
>>  request.onsuccess = function(evt) {...};
>>  request.onerror = function(evt) {...};
>>
>> It looks *very* wrong to me:
>>
>> What should happen if db.open() will open the DB immediately?
>
> The event fires asynchronously. Since JS is single threaded that means
> that the onsuccess and onerror properties will be set before the event
> is fired.

1. Who said that JS *must* always be single threaded?

2. Is there any requirement that IndexedDB must be used only with JS?

3. Are you sure that opening DB or doing look-up on b-tree is always
   more expensive than posting and dispatching events? Windows
   for example uses 18ms precise timers ( used for dispatching
   non-UI events, or similar mechanism ).
   Are you saying that all operations in IndexedDB simply cannot work
   faster than that? If "yes" then who needs such brake by design?

If to compare look-up in b-tree on memory pages that are already in
cached and the task of posting/dispatching messages including
handler function invocation in script then ratio will be around 1:50.
What's the name of the design that puts such overhead upfront?

>
>> Will request.onsuccess be called in this case?
>
> Yes.
>
>> If indexedDB.open is purely async operation then
>> why it has to be exactly async?
>
> Because it requires IO.
>

1. Why exactly it requires IO? Why it cannot be implemented by using
    main memory or memory-mapped files at the end ( not exactly IO
    in classic sense )?
2. localStorage also uses IO, what's the problem you see with it at the
    moment?
3. Which operation in IndexedDB require significantly more
    time to execute than corresponding one from localStorage?
4. What's wrong with Web Workers that were designed specifically for
    cases when operations takes long time? I do not see what
    operation can take long time in IndexedDB but still would like
    to know answer.

>> What may take time there other
>> than opening local file in worst case? If that request is async then
>> when precisely request.onsuccess will be called?
>>
>> I would understand if DB.open call will be defined this way:
>>
>> function onsuccess(evt) {...};
>> function onerror(evt) {...};
>>
>> var request = indexedDB.open('AddressBook', 15, onsuccess, onerror );
>>
>> (so pure callback operation).
>
> If I write
>
> var x = 0;
> function onsuccess(evt) { x = 1 };
> function onerror(evt) {...};
> var request = indexedDB.open('AddressBook', 15, onsuccess, onerror );
> console.log(x);
>
> would you expect the console to sometimes show 1 and sometimes show 0?
> If not, why not?

I am not sure I understand you here.

This form:
   indexedDB.open('AddressBook', 15, onsuccess, onerror );

does not limit UA engineers to chose the most optimal implementation.
So such open() may or may not use async model. But current spec
mandates the most ineffective variant. By design.

But in general there is no need for callback/events for operations on
such small DBs. SQLite API does not have async operations... Why
IndexedDB needs it? And SQLite data operations are potentially more
expensive by order of magnitude than in that IndexedDB ...

Beg my pardon for such many questions.

-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Saturday, 9 March 2013 07:59:34 UTC