On Aug 10, 2009, at 11:55 AM, Mark Sapiro wrote:
Barry Warsaw quoted:
On Aug 8, 2009, at 4:25 AM, Malveeka Tewari wrote:
I also want to make sure that in the database I am caturing all the Memberships data. Presently my database uses the following class as a storm abstraction for the database. Do I need to add/remove anything?
class PgsqlMembers(object): __storm_table__ = "mailman_test" __storm_primary__ = "listname","address"
listname = Unicode() address = Unicode() password = Unicode() lang = Unicode() name = Unicode() digest = Unicode() delivery_status = Int() user_options = Int() topics_userinterest = Unicode() bounce_info = Unicode()
This has caused problems with the MySQL MemberAdaptor in the past. bounce_info is a _BounceInfo class instance that is supposed to be opaque to the MemberAdaptor. The issue with the MySQL MemberAdaptor was that it 'knew' what the attributes of this instance were and stored them separately in the database, but then the class grew another attribute and the MemberAdaptor failed.
The problem is that the methods setBounceInfo() and getBounceInfo() have to know something about the _BounceInfo class in order to be able to store something in the database that can later be returned as a class instance.
The MySQL MemberAdaptor does this by hving setBounceInfo() store the attributes separately and getBounceInfo() instantiate the class with the retrieved attributes, but this fails if the number of arguments expected by _BounceInfo.__init__() changes.
This has been a PITA in MM3 too, and not something I've totally
unfscked yet.
An alternative is to pickle the class instance into a string to be stored in the database, but this then loses the ability to see the various bounce attributes in the database.
The nice thing is that Storm has a Pickle() type that makes it easy.
But you're right, doing this is only a stopgap and makes the bounce
information opaque to other proceses.
-Barry