[Mailman-Developers] Another take at MysqlMemberAdaptor + a migration util

[Adrian Wells]

"Kyrian (list)" <kyrian-list at ore.org> on Friday, November 04, 2005 at 7:05
PM wrote:
>If anyone else feels like testing it, I have fairly silently uploaded the
>latest
>version (1.69) of it to the oRe Net Opensource pages, although that has
>only been tested to the point of a python syntax check pass.


Thank you for releasing this version.  There is a change in this version
which caught my attention but I do not understand - that is the size of
the varchar address column when creating table for the 'wide' format:

@@ -118,7 +118,7 @@
 ) TYPE=MyISAM""" )
                else:
                        self.cursor.execute ("""CREATE TABLE IF NOT EXISTS
%s (
-  address varchar(255) NOT NULL,
+  address varchar(100) NOT NULL,
   hide enum('Y','N') NOT NULL default 'N',
   nomail enum('Y','N') NOT NULL default 'N',
   ack enum('Y','N') NOT NULL default 'Y',


I do not believe that this column length should be reduced to 100. 
Although it appears this might have been a typo when reducing the size of
the varchar listname column from 255 to 100 for the 'flat' format.


>* Figure out how to make passwords work. Currently using "!" as the
>default
>  password, so that things don't barf, but that is probably not the right
>  way to go about it. What is the Mailman equivalent of "No password",
>etc?


As it is now, passwords seem to work... at least one can login via the web
browser based interface using a member password to change member options
(including successfully changing a member password).  Is this comment
specific to "No password" conditions?  If that is the case, then I agree
with Fli's suggestion (which I understand as simply assigning a random
password instead of "!" as the default password).  A member can receive
this randomly generated password if it is needed.

>
>* Ensure that what the patch is doing ties up with Barry's input wrt.
>  what it should be doing.


Is there more background on this?  It seems like something was discussed
off-list, perhaps?  Or I simply missed a discussion.


>* Check up on whether Adrian Wells is correct with regards to the user
>flags
>  ('hide', 'noemail', 'ack', 'not_metoo', and 'plain'), and hence columns
>  in the adaptor's database tables are fully deprecated from Mailman, in
>  favour of the user_options flag/column if so, make changes to the
>adaptor
>  accordingly.


Minor correction:  'noemail' should be 'nomail'.  These findings were
originally based on the fact that version 1.61 of this adaptor did not
insert or update any of these columns.  Additionally, some time was spent
determining how the 'user_options' column stored various settings by
making changes and observing results (not the most efficient method).  The
following is a list of how things appear to break down:  'user_options'
column is a sum of the following options:

NO OPTIONS selected = 0
not metoo = 2
ack = 4
plain = 8
hide = 16
mod = 128
no dupes = 256

>
>* Adrian Wells Bouncer.py patch. Discuss with Mailman team. Is it the
>right way
>  to go. Moving this patch deeper into the guts of mailman seems to be a
>little
>  anathema to the whole idea of Member Adaptors in the first place, not to
>  mention that it scares me a little ;-)


To be more accurate, Mark Sapiro helped to refine this patch, and he
provided valuable insight and suggestions about this: 
<http://mail.python.org/pipermail/mailman-developers/2005-October/018271.html>.

Barry Warsaw also recommend to "pickle the BounceInfo object on the way
into the database, and unpickle it on the way out": 
<http://mail.python.org/pipermail/mailman-developers/2003-November/016036.html>.
>
>
>* PRIORITY: Database escaping, need to work out how to to this with the
>Python
>  MYSQLdb module, after all it would only take a well-crafted email to
>raise
>  merry hell as things are at the moment.


Not that I'm looking for a proof of concept here, but I'm interested in
knowing how this is an issue.  Like Fil, I don't see an issue but I may be
overlooking something obvious.  Maybe this would be best
answered/discussed after the issue was resolved.

-Adrian