[ZODB-Dev] Persistent Mapping Classes

[Tim Peters]

[Ron Wills]
> Ok, I'll simplify.
> ...

Ron, can you supply a self-contained test program, demonstrating the
problem, that other people can run?  There are many errors in the "well,
it's kind of _like_ this" snippets you're giving us, to the point that I
can't guess what may be important.

For example,

>     del __len__(self):

You didn't run the code you pasted there, since "del" should be "def".  Then

> db = DB(filestore)
> conn = DB.open(db)

couldn't have worked either; you probably intended

  conn = db.open()

instead.  The next line can't work either:

> conn.root['SomeClass'] = OORTable(SomeClass)

conn.root() was intended.  Fix that, and it still blows up, because your
OORTable.__init__ referenced a variable that doesn't exist.

That's not the last of the problems, and, in the end, as Victor noted the
code didn't commit the transaction, so there was no reason to _expect_ the
changes to persist.  When I repaired that too, I ended up with a pair of
programs that didn't show any problem -- each time I run them, my

    print len(ootable)

prints 0 to the console.

> ...
> Why this is happening or to give consistent testing for the failure
> is beyond me, and unfortunately I cannot freely share the code as
> this is a contracted commercial product :(.

I appreciate that, and don't really want all your code anyway ;-)  What I
want is a minimal, self-contained failing example we can actually run as-is.
You also said:

>  all other methods of the class are for our query engine and importing
> routines from a third party sql db. This is not the source of the
> problem and can be removed.

and that's what would help:  remove _everything_ that's irrelevant to the
problem, and share what's left (I assume here that the proprietary part of
your code is in the query engine, and you say that's not relevant to the
problem, so it should be able to create a failing example that doesn't use
that part).