[Mailman-Developers] SQL MemberAdaptor implementation?

[Barry A. Warsaw]

>>>>> "DN" == Dale Newfield <Dale@Newfield.org> writes:

    DN> OK--I think I've found the time to build this and contribute
    DN> it to the cause!

Very cool!

    DN> Just want to make sure that none already exists...  Has anyone
    DN> built such a beast?

Not that I know of.

    DN> Are there *any* other known implementations to use as
    DN> references besides OldStyleMemberships.py?

Not that I know of.

    DN> I'm also wondering about dynamic groups...  (and think that I
    DN> should be able to implement this using some combination of the
    DN> "virtual" list and the "extended" list.)

That's definitely the intent.  No one's tried it, so you're
bushwhacking here, but I'll try to accomodate for MM2.1 if it isn't
too disruptive.

    DN> In the system that I'll be integrating this there are several
    DN> types of entities, and a dynamic number of instances of each.
    DN> I'd like to be able to have each instance of each entity have
    DN> it's own (probably virtual) mailing list.  The first idea is
    DN> to create one concrete mailman list (with
    DN> settings/templates/etc.) for each type, and have each instance
    DN> automagically exist with distinct membership (as pulled from
    DN> the SQL DB).

    DN> As a more concrete example, I might want to set up a "class"
    DN> mailing list and a "project" mailing list, but I really want
    DN> it to appear that there are many mailing lists all of the form
    DN> "class+phys101@domain.edu", "class+ee382@domain.edu",
    DN> "project+planQ@dom.ain", "project+noFNORDs@dom.ain", etc.
    DN> (The plus'es are a straw-man, it could be deliniated some
    DN> other way--the key is that I want them each to have a distinct
    DN> email address so that people can respond to the group if
    DN> desired--if this were announce-only I could simply use the
    DN> virtual list and .inject() method.)

Sounds good so far.

    DN> Any suggestions as to how to go about this?  I'm guessing I'll
    DN> make an SQL DB framework that is only mostly concrete.  Each
    DN> list would need an extend.py that informs that framework about
    DN> the schema through which to find various pieces of information
    DN> in the DB.  Any suggestions as to how that schema should be
    DN> specified?

I'm out of my league when it comes to SQL hacking, so I can't help
much there, but there are some implicit assumptions in MemberAdaptor
that you need need to keep in mind.  I think most of these are
described in the MemberAdaptor.py docstring (re-reading that now...).

The bit about "member keys" and lce's may be inaccurate.  I think in
general the assumption is that an lce is the key to the member's
information, and I doubt you can use something more opaque.  But you
could try it and we could fix breakages.

    DN> This brings up something about which I'm not so clear--can
    DN> different lists use different MemberAdaptors?

Yes, definitely.  The do now <wink>.  If you wanted to federate the
user databases for several lists, you'd have to coordinate that
through the concrete adaptor, or backend.

    DN> Can I have a single mailman instance running some lists with
    DN> OldStyle and other lists using my new fangled system?

I believe so.  What your extend.py needs to do is set
self._memberadaptor to the instance of your SQL adaptor.  All relevant
calls will be made through that object.

The tricky part, and the part I'm less confident about, is that you
need to coordinate transaction boundaries through MailList.Load() and
MailList.Save().  Save() is essentially "commit", but we never Save()
if there's nothing to do, or if we don't have the list lock.

-Barry