Hi Shaun,
Shaun Cutts wrote:
Ah -- very nice: so Data.fs *is* a transaction log.
Yup, and a very simple, robust one at that ;-)
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).
Well, if you worry about this, fork out for ZRS, which writes all your
transactions to multiple back end storage servers...
But with replication, this issue is taken care of. (Too bad replication
isn't part of the core functionality....)
You can always do application-level replication ;-)
Section 3.1... so ZODB is effectively doing MVCCS and with per-object
locks to resolve conflicts.
Someone else explained how Zope 2.8+ is now even better with this :-)
(Question: can one explicitly lock an object
without changing it? I guess just setting _p_changed?)
No, 'cos that would also mean that a copy of the object got added to the
end of Data.fs when the current transaction is committed, which is done
by Zope's publisher...
3) general lack of query language potentially problematic for
datamining
catalogs are your friends...
cheers,
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
_______________________________________________
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
