On Aug 8, 2009, at 4:25 AM, Malveeka Tewari wrote:
I am working on writing a storm based member adaptor for mailman so
that the mailman membership data can be stored in a database instead of .pck
files. The reason for choosing storm is that it provides an abstraction to
use any underlying db language- either mysql, postgresql or sqllite.
I'm a big fan of Storm. It's the ORM used in Mailman 3 and I've had a
lot of good success with it.
Please note that this new member adapter cannot go officially into
Mailman 2.1, but I do think it might be useful for Mailman 2.2,
probably as unofficial contrib, though Mark may want to weigh in on
that. Because the schema is so different in Mailman 3 and we already
use Storm, this won't be relevant for that branch.
The ideal case would be to use only a database and no pickle files for Memberships data but I have not reached there. I had tried to read and use the data from the database instead of
pickle files and that had broken my Mailman which leaves me with few
questions
Are you using Pickle() fields for non-scalar data types? (i.e. lists
and dictionaries). Of course, you don't gain from relational data
that way, but it's still useful.
In OldStyleMemberships.py the lower cased email address is used as a
key for accessing the membership properties. However in my schema, I am using the (listname, case preserved email address) as the PK. Is it possible that not storing and using LCE as a key might break something.
From OldStyleMembership's (very loose) contract, I think the answer
is "yes". It doesn't matter so much how you store things in the
database, but you will have to honor the contract that the
MemberAdapter.py promises.
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() delivery_status_timestamp = Unicode()
When I was creating the schemas for MM3, I basically had to inspect
OldStyleMembership.py to see what fields it requires, then fix things
as tests broke. MM2 has the great disadvantage that there isn't a
usable test suite. This is fixed in MM3. So I think you're left to
manual testing until it basically works for you. :(
-Barry