[Mailman-Developers] Re: Mysql MemberAdaptor Load/Save/Lock/Unlock

[Kyrian (List)]

Dale, et al,

> I don't think I understand how you reconcile Mailman's load/save
> transaction units with sql's transaction.
> 
> There are places in mailman where a list is loaded and manipulated,
> but not saved...
> 
> ...does your code basically change the semantics so that effectively a
> "save" happens after every single state change, yet the "save" method
> is a no-op?
> 
All I've done is implemented the Mailman 2.1 MemberAdaptor API as-is
against a MySQL (which, incidently doesn't support transactions by
default, unless they've started making InnoDB tables the default type)
backend, without changing the semantics of anything(AFAIK), the only
changes of any import that I've made are that the Member data structures
are stored in a way that fits MySQL and converted as they are loaded to
the way that fits Mailman, which you'd expect...

It saves when a save method is called, loads when a load method is
called, but that API doesn't include a lock and unlock method, so I've
not implemented one (although I've left calls to 'self.__mlist.Locked()'
in the code where they're appropriate, ie. where they are in
OldStyleMemberships.py too).

If there are changes being made to the data internally to the rest of
Mailman that don't make calls to the MemberAdaptor API, then they are
unaffected by my additions, and consequently they won't be having any
effect on the MySQL database.

However, having thought about it, you're probably talking about changes
to the base structure of the list (name, footer, header, all that
stuff), which isn't covered by the MemberAdaptor API, and hence I've not
touched on. 

If an API for that purpose were provided (which AFAIK is pending, but
not there yet, except maybe in CVS?), then I'd write the code for a
MySQL backend, but I don't think I could, or should play about with the
internals of Mailman beyond that. I just don't understand either Python
or Mailman enough at that sort of level to do so, and I certainly don't
want to introduce any obscure and nasty bugs into the core code...

Please do correct me if I'm wrong on any of this?

K.

-- 
Kev Green, aka Kyrian.       "Be excellent to each other" -- Bill & Ted.
   Email: kyrian@ore.org              Web: http://kyrian.ore.org/
  ISP/Perl/PHP/Linux/Security Contractor, via http://www.orenet.co.uk/