Re: Persistent Storage vs. Database

On Fri, Mar 8, 2013 at 12:36 AM, Kyle Huey <me@kylehuey.com> wrote:

> On Thu, Mar 7, 2013 at 10:20 PM, Andrew Fedoniouk <
> news@terrainformatica.com> wrote:
>
>> Physical commit (write) of objects to storage happens on either
>> a) GC cycle or b) on explicit storage.commit() call or on c) VM shutdown.
>>
>
> Persisting data off a GC cycle (via finalizers or something else) is a
> pretty well known antipattern.[0]
>

Correct, but just to be clear, there are other ways to get a similar
effect.  In particular, you can queue a task, add a job to the "global
script clean-up jobs" list, or use a microtask.

At least it is easier than http://www.w3.org/TR/IndexedDB/ :)
>
>
Note that if you see "TR" in a URL, you're probably looking at an old,
obsolete spec.  This one is almost a year out of date.  Click the "editor's
draft" link at the top to get to the real spec.
https://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html

On Fri, Mar 8, 2013 at 1:02 PM, Andrew Fedoniouk
<news@terrainformatica.com>wrote:

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

This is wrong.  Events are not an "antipattern" (calling things that seems
a bit of a fad these days), and they're certainly not a "proposal".  It's
the standard, well-established API on the Web, used broadly across the
whole platform.

-- 
Glenn Maynard