Re: Persistent Storage vs. Database

On Fri, Mar 8, 2013 at 12:36 AM, Kyle Huey <> wrote:

> On Thu, Mar 7, 2013 at 10:20 PM, Andrew Fedoniouk <
>> 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 :)
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.

On Fri, Mar 8, 2013 at 1:02 PM, Andrew Fedoniouk

> 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

Received on Friday, 8 March 2013 23:27:54 UTC