Andreas Jung wrote:
--On 22. Juni 2008 08:49:32 -0700 tsmiller <[EMAIL PROTECTED]>
I have been using the ZODB for about a year and a half with a bookstore
application. I am just now about ready to put it out on the internet for
people to use. I have had the same problem with saving data. I have
tried alot of things. But I have never gotten the database to save
consistently. I can create an x number of records one right after the
other that uses the exact same code to save them, and it is likely that
all of them will save perfectly except one - or maybe two.
We have never seen that - except with badly written application code.
Commiting a transaction should always commit the data. That's the sense
of a transaction system. The only reason I can imagine causing such a
bare try..except with in your code suppressing ZODB conflict errors.
The other likely cause of this is modifying non-persistent sub objects
and not setting _p_changed = True on the parent persistent object. e.g:
>>> dbroot['a_list'] = [1, 2, 3]
>>> a_list = dbroot['a_list']
The second commit actually has no effect as the persistence machinary
has not been notified that the object has changed. This is not
immediately apparent though as the 'live' shows what you expect:
[1, 2, 3, 4]
And if a later transaction also modifies the persistent object, then all
of the data is saved.
To avoid this, avoid using mutable, non-persistent types for storage in
the ZODB, replace lists and dicts with PersistentList and PersistentMapping.
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org