Re: Persistent Storage vs. Database

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

> 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.

> 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.

> 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?

/ Jonas

Received on Saturday, 9 March 2013 04:17:57 UTC