[Mailman-Developers] Questions in regard to the database operations

[Barry Warsaw]

On Jun 27, 2012, at 10:23 AM, Ian Eiloart wrote:

>> There is an IPreferences interface which describes the kind of things that
>> are "preferences".  Members, users, and addresses all can have a pointer to
>> a preferences record.  There are also some system default preference
>> values.  When we look up a preference on a member, the search order goes
>> like this:
>> 
>> * member
>> * address
>> * user
>> * system

>Do you mean "membership"? If I (a user) am a member of a list, then I have a
>membership record.

It means that you-the-user or you-an-address-you-control is linked to the
mailing list through the member record.

>But, the member is the user.

Not really.  It's perfectly valid for a member record to link a mailing list
to an address which is not associated with any user record.  Members link
addresses to mailing lists.  The shortcut of linking a user to a mailing list
is only valid if that user has a preferred address.

>If the term "member record" is used to describe a membership record, things
>are going to get confusing, I think. Or, perhaps it's a subscription (but
>still not a subscriber) record?

Member records represent subscriptions to mailing lists as a recipient of
messages sent to the list.  But they also represent other mailing list roles,
such as list-owners and list-moderators.  So let's say anne at example.com is a
member of a mailing list, and the list owner.  Her address record will be
linked to two member records, one with role "member" and the other with role
"owner".

This might seem confusing at first, but I've lived with this terminology for a
long time, after many clarifying steps, and I think this works the best.  Once
you understand the relationship of users, addresses, members, and mailing
lists, it shouldn't be confusing.

>To be more explicit, I'd expect a "members" table to simply list references
>to users.

It can't because of the types of relationships we want to support, such as:

 - A user subscribing multiple addresses to a mailing list.
 - A user serving more than one role for a mailing list.
 - Subscribing non-user addresses to mailing list, e.g. mailbots
 - Subscribing a user's preferred address, which can easily be changed
   system-wide.

Memberships link addresses to mailing lists.  They *can* link a user to a
mailing list, but only if that user has a preferred address.

>Whereas a "subscriptions" or "memberships" table would include references to
>members, as well as information about the subscription (preferred mailing
>address, start date, permission type, subject line munging, etc, etc).

I'm not sure what a "member" would be if not essentially equivalent to a
subscription.  IOW, when you say "expect a members table to simply list
references to users", I don't see how that's useful as an independent
concept.

>My guess is that the link to users is implied, though? 

In the case where a member links an address to a mailing list, and that
address is linked to a user, then you're correct. :).

Through queries (hidden behind other interfaces, such as the IRoster) we can
always find the list of users that are subscribed to a mailing list, although
of course user-less addresses won't show up there.

Stephen did a pretty good job of explaining all this very succinctly.  A
diagram would help, but I suck at ascii art. ;)

http://packages.python.org/mailman/src/mailman/docs/8-miles-high.html#user-model

Contributions welcome of course!

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120627/b9bfda0b/attachment.pgp>