ZODB for Javascript?

[Christopher Lozinski]

I really like the ZODB. I am surprised that there is nothing like
ZODB for Javascript. Is there something about python that makes ZODB
possible in python, but not in Javascipt, or is it just that no one has
yet written a clone of ZODB in Javascipt?

Thanks
Chris

[Laurence Rowe]

A number of JSON document databases exist: Couch, Mongo, Elasticsearch, Postgres, etc. I've found them to provide a fairly ZODB-like development experience.

For full transparent persistence I think we'd have to wait for ES6 Proxy objects to be implemented more widely. JavaScript hasn't had an equivalent to Python's __getattr__ up to now which would be required to implement transparent reference loading.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy

Transparent reference loading implies blocked fetching, so I'm not sure it would fly in the async JS world.

Laurence

[Jim Fulton]

I wonder what you mean by "ZODB for JavaScript". To me, ZODB means:

- "Transparency", which means the ability to write persistent
applications with minimal intrusion:

- Dealing with more or less arbitrary object, not just "documents"
connected in webs that can be as complex as necessary.

- Implicit object loading through object access.

- Letting the system keep track of what has changed.

- True transactions that span multiple objects. This overlaps more
with RDBMSs than with most NoSQL databases.

- A replication-based caching model. A ZODB database connection is a
consistent replica of a database. It's not all loaded into memory,
but the bits in memory are consistent and remain so as of the
transaction start. Replicas are kept up to date via real-time
invalidations.

This model has strengths and weaknesses. If an application has a
working set that fits mostly in memory, and if write rates aren't
too high, then it's extremely efficient, at least it is once the
cache is populated.

OTOH, with high right rates and large numbers of clients, the
invalidation model may become too expensive. And some applications
have large working sets that don't benefit much from caching.

JavaScript presents some special challenges. The greatest, I suspect
is it's radically asynchronous nature. While JavaScript has
synchronous APIs, the trend is toward asynchronous APIs. This is
especially challenging for databases, and especially for providing
natural object access. When ZODB automatically loads an object on
access, that's synchronous. It's hard to see how it could be anything
else.

If you want to make your head hurt, try to figure out how transactions
work in IndexedDB. IndexedDB seems to be poorly baked and poorly
adopted and I suspect it's insanely asynchronous access model is some
of the reason why.

Asynchronous models make a lot of sense for some use cases. I often use
them, however, religiously applying them everywhere is foolish, IMO.

Jim

--
Jim Fulton
http://jimfulton.info

[Fulvio Casali]

There is always http://zodb.ws/ ... 

;-)

(note the release date https://twitter.com/zodbwebscale)

[Jim Fulton]

On Sun, May 17, 2015 at 11:44 AM, Fulvio Casali <fulvio...@gmail.com> wrote:
> There is always http://zodb.ws/ ...
>
> ;-)

Problem solved!

[Christopher Lozinski]

http://www.reddit.com/r/Python/comments/3aoseb/is_it_a_bad_idea_to_use_zodb_for_a_customer/