[Mailman-Developers] Storm based MemberAdaptor for Mailman
mark at msapiro.net
Mon Aug 10 17:55:24 CEST 2009
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
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.
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.
>> delivery_status_timestamp = Unicode()
Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
More information about the Mailman-Developers