[Zope3-Users] zodb objects backup

[Shaun Cutts]

Gary,

Thanks again for your patient answers to all my questions.

I'm trying to think of reasons why ZODB would not work in advance (as
ZODB master/postgres slave), as this is a fundamental decision which
would take much too much time to undo, and scalability testing is also
time consuming.

So far so good, modulo the replication issue. (We don't have much
funding yet... but if initial launch goes well, we're hopeful :)).

It would be very nice if there were a faq or other doc addressing all of
these scalability-related questions systematically for someone like me
who understands what a relational database is doing for them (in return
for squashing all their objects). It seems I'm not the only one with
these concerns. :)

WRT benchmarks, there are several standard benchmarks for SQL databases.
If  one of these had been ported to ZODB, even if it wasn't an exact
fit, it would be quite a relief to know, starting out, that "well, I
don't know how it will do on my application, but I know that it probably
is within a factor of 2 or 3 of Postgres performance on something
vaguely similar, so if I do have problems, I should be able to roll up
my sleeves and fix them with suitable optimization or in the worst case
buying new hardware, but not that much more than I'd need with
Postgres."

...

In the meantime, I had an idea about my current implementation: maybe
instead of __getstate__ and __setstate__ I should put the external data
in _v_data (marking as "volatile"). Then I could trap for its existence,
and load if necessary; and also have an explicit "refresh" wired to a
button in the GUI. (Later, if Postgres was still the master, I could
write a db trigger to set per-table update timestamp, accessible without
doing a full requery.)

- Shaun