Ah -- very nice: so Data.fs *is* a transaction log. In theory an RDBMS
with write ahead logging is still more secure because the transaction
log is only backup, and the rest of the database is another copy of the
current state (though not with undo capability).
But with replication, this issue is taken care of. (Too bad replication
isn't part of the core functionality....)
Also nice is
Section 3.1... so ZODB is effectively doing MVCCS and with per-object
locks to resolve conflicts. (Question: can one explicitly lock an object
without changing it? I guess just setting _p_changed?)
Are there any benchmarks available?
We can't abandon Postgres entirely:
1) we have custom aggregate statistical functions in C
2) we have to allow third-party ODBC access to certain views
3) general lack of query language potentially problematic for
But 1)-2)-3) for us are "read-only" needs, so in theory, with
replication, we could use Postgres as a slave to ZODB master.
Again, benchmarks would be nice. We haven't yet speced out, let alone
bought, the hardware for our production system, so I couldn't yet say
how high the bar is.
> -----Original Message-----
> From: Gary Poster [mailto:[EMAIL PROTECTED]
> Sent: Saturday, February 25, 2006 3:39 PM
> To: Shaun Cutts
> Cc: Alen Stanisic; firstname.lastname@example.org
> Subject: Re: [Zope3-Users] zodb objects backup
> Alen, please see
> Shaun, many of the other questions in this thread--and others
> recently--are answered in this guide:
> It is highly recommended reading if you are doing serious Zope 3 apps.
> Both of these are found in the ZODB wiki, which has some other
> helpful docs:
Zope3-users mailing list