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 _______________________________________________ Zope3-users mailing list Zope3firstname.lastname@example.org http://mail.zope.org/mailman/listinfo/zope3-users