[Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman: [8184] trunk/mailman/Mailman

Barry Warsaw barry at python.org
Fri Mar 30 14:10:11 CEST 2007

Hash: SHA1

Hi Tokio,

On Mar 30, 2007, at 7:16 AM, Tokio Kikuchi wrote:

> Wow!  Fix is so simple.

I know!  I was shocked too. :)

> Mere Load() can't refresh the list attributes but needs Lock() to get
> them.  A few problem remains like decorating the message where
> OutgoingRunner is used.  This runner don't update the database so it
> doesn't use Lock() but only Load().  We should fix them to use Lock()
> (and Unlock()) to reload data.

Funny, I did probably the exact same test as you did. :)

You're right that the Lock() is necessary to refresh state, so it my  
indeed be better to put this change on Load(), or to fix those few  
other places to use Lock() to refresh.  But I also worry that this  
isn't a full solution ultimately.

The problem is that this will only refresh MailList objects.  I'm  
still trying to find time to port my PyCon changes back into the  
trunk, and part of those changes begins to exchange the PickleType  
columns for real tables.  Refreshing the MailList I suspect won't  
refresh those tables so we'll need to add each related table to the  
refresh set.  I'm going to try to contact the SQLAlchemy folks to see  
if there isn't a more general, or better way, of doing what we're  
trying to do here.  There may not be though because istm that an  
application still needs a way of clearly defining such reload  
boundaries.  Mailman's way is through MailList.Load()/.Lock()/.Unlock 
(), which is tied to that class.

Still, it's important to be aware of this issue, so I'd like to get  
the SA folks take on it.

Thanks for testing this out!
- -Barry

P.S. I'm still getting 3 failures in the test suite.  You mentioned  
it's because we're using different email packages.  I'll try to  
figure that out this weekend.


Version: GnuPG v1.4.5 (Darwin)


More information about the Mailman-Developers mailing list