[ZODB-Dev] connection.sync() kills _p_changed?

[Greg Ward]

On 13 July 2001, Christian Robottom Reis said:
> This is one type of object in a very large set. I have a collection of
> persistent domain objects, each arranged in it's own catalog and providing
> references to a whole set of others. The ZODB gives me what I want -
> distributed data through the ZEO, transparent persistence, transactions.

Yeah, I know what you mean!  ZODB and ZEO are large and complicated
beasts, but they do a *hell* of a lot of neat stuff.

> If I had to home-cool a bsddb3 persistence solution, I'm sure it would be
> a big headache, and would hardly look as solid as the ZODB. Besides, there
> wouldn't be Greg Ward around to give me a hand while I was at it :-) So
> bear with me for a bit, I'm a fast learner when I'm at it.

*blush* (Actually, for my real work I use ZODB/ZEO, because we need it.
But for another project (SPLAT!, a small bug-tracker which I plan to
release and distribute one of these days), I decided to use bsddb3.
First, I wanted to see how much bother it is to handle persistence
youself.  (Not too much, but you have to carefully plan your interface
to ensure that clients always go through the methods that load objects
if needed.)  Second, bsddb3 is (I think) a much smaller pill for someone
to swallow if they want to run SPLAT!.  But I'm still learning my way
around the Berkeley DB 3.x library -- it, too, is a large and
complicated beast.  Sigh.  Let's face it, databases are hard.

> Yes, it is. However, there's a bit of trickery here. I'm using a graphical
> client, and I've come to see that graphical interfaces represent another
> sort of 'Impedance Mismatch' to my application classes.

Our big app has mainly web interfaces (with some command-line scripts
for admin use), so that's not as much of a problem: the web is so slow,
it doesn't really matter if you copy every piece of data from one Python
string to another.  Might be different with a real GUI.  Gut instinct
(and a tiny bit of experience) tells me one thing: keep your UI
classes/objects out of your database, and keep your persistent data out
of your UI classes/objects.  If your UI classes let you connect the GUI
toolkit directly to attributes of your persistent objects, great -- do
it that way and save the overhead of copying.  But it's probably better
to put up with copying values to/from the UI than to mix up UI and
database.

        Greg
-- 
Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange                            http://www.mems-exchange.org