[Mailman-Developers] SQL MemberAdaptor implementation?

[Dale Newfield]

On Tue, 20 Aug 2002, Barry A. Warsaw wrote:
> 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.

I will try to make that opacity work.  A question, though, is what
conceptually that key should represent.  Does it represent a user, or a
user's subscription (which is a one-to-many relationship)?

> 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.

Hrm.  So you're suggesting that all modifications made through the
writable interface be queued up in a transaction that isn't committed
until .Save()?

But then this could happen:
Q: What is Bob's subscription style to XYZ.?
A: normal

Change him to digest mode.

Q: What is Bob's subscription style to XYZ.?
A: normal

Basically it seems that the "don't commit until .Save()" and the "all
state changes happen immediately" contradict one another...

-Dale