summaryrefslogtreecommitdiff
path: root/Mailman/interfaces/database.py (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Bite the bullet: rename the Mailman package to mailman.Barry Warsaw2008-02-271-83/+0
|
* The start of a cleaning up of Errors.py. Eventually, I want to get rid ofBarry Warsaw2008-02-191-0/+20
| | | | | | | | | this module, in favor of moving exceptions into the interface modules that they are appropriate for. For now, this is just the low-hanging fruit. Along the way, clean up by reSTifying some interfaces and implementations.
* Tweak copyright years.Barry Warsaw2008-02-071-1/+1
|
* Fix two doctests: addresses.txt and mlist-addresses.txtBarry Warsaw2007-11-071-3/+0
| | | | | Remove flush() altogether. Yee-haw! Rework queries to be Stormy. Fix doctests to be Unicode-ish.
* Much progress, though not perfect, on migrating to SQLAlchemy 0.4 and ElixirBarry Warsaw2007-10-311-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 0.4. Lots of things changes, which broke lots of our code. There are still a couple of failures in the test suite that I don't understand. It seems that for pending.txt and requests.txt, sometimes strings come back from the database as 8-bit strings and other times as unicodes. It's impossible to make these tests work both separately and together. users.txt is also failing intermittently. Lots of different behavior between running the full test suite all together and running individual tests. Sigh. Note also that actually, Elixir 0.4.0 doesn't work for us. There's a bug in that version that prevented zope.interfaces and Elixir working together. Get the latest 0.4.0 from source to fix this. Other changes include: - Remove Mailman/lockfile.py. While I haven't totally eliminated locking, I have released the lockfile as a separate Python package called locknix, which Mailman 3.0 now depends on. - Renamed Mailman/interfaces/messagestore.py and added an IMessage interface. - bin/testall raises turns on SQLALCHEMY_ECHO when the verbosity is above 3 (that's three -v's because the default verbosity is 1). - add_domain() in config files now allows url_host to be optional. If not given, it defaults to email_host. - Added a non-public interface IDatabase._reset() used by the test suite to zap the database between doctests. Added an implementation in the model which just runs through all rows in all entities, deleting them. - [I]Pending renamed to [I]Pended - Don't allow Pendings.add() to infloop. - In the model's User impelementations, we don't need to append or remove the address when linking and unlinking. By setting the address.user attribute, SQLAlchemy appears to do the right thing, though I'm not 100% sure of that (see the above mentioned failures).
* Refactor IDatabase interface so that the user_manager, list_manager,Barry Warsaw2007-08-021-0/+3
| | | | | message_store, and pendings 'databases' hang off the IDatabase object attached to the config object. For IPending, no adaptation is necessary.
* Move the pending database into the SQLAlchemy/Elixir layer. The oldBarry Warsaw2007-08-011-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pending.py module is removed. Added an interface to this functionality such that any IPendable (essentially a key/value mapping) can be associated with a token, and that token can be confirmed and has a lifetime. Any keys and values can be stored, as long as both are unicodes. Added a doctest. Modified initialization of the database layer to support pluggability via setuptools. No longer is this layer initialized from a module, but now it's instantiated from a class that implements IDatabase. The StockDatabase class implements the SQLAchemy/Elixir layer, but this can be overridden in a setup.py. Bye bye MANAGERS_INIT_FUNCTION, we hardly knew ye. Added a package Mailman.app which will contain certain application specific functionality. Right now, the only there there is an IRegistar implementation, which didn't seem to fit anywhere else. Speaking of which, the IRegistrar interface implements all the logic related to registration and verification of email addresses. Think the equivalent of MailList.AddMember() except generalized out of a mailing list context. This latter will eventually go away. The IRegistrar sends the confirmation email. Added an IDomain interface, though the only implementation of this so far lives in the registration.txt doctest. This defines the context necessary for domain-level things, like address confirmation. A bunch of other cleanups in modules that are necessary due to the refactoring of Pending, but don't affect anything that's actually tested yet, so I won't vouch for them (except that they don't throw errors on import!). Clean up Defaults.py; also turn the functions seconds(), minutes(), hours() and days() into their datetime.timedelta equivalents. Consolidated the bogus email address exceptions. In some places where appropriate, use email 4.0 module names instead of the older brand. Switch from Mailman.Utils.unique_message_id() to email.utils.make_msgid() everywhere. This is because we need to allow sending not in the context of a mailing list (i.e. domain-wide address confirmation message). So we can't use a Message-ID generator that requires a mailing list. OTOH, this breaks Message-ID collision detection in the mail->news gateway. I'll fix that eventually. Remove the 'verified' row on the Address table. Now verification is checked by Address.verified_on not being None.
* Add setuptools plug-in entry point for defining different database backends.Barry Warsaw2007-07-241-0/+48
Now someone could distribute a setuptools package that provided say, a MySQL database implementation and very easily override the stock database. How awesome is setuptools? Removed MANAGERS_INIT_FUNCTION since setuptools gives us a much more standard way of defining this plug-in entry point. Remove other old crud from Defaults.py. Restructure our own 'stock' database backend to be a plugin so it's totally on par with any other package. The only special case is that if more than one such entry point is defined, we filter out the 'stock' one (i.e. ours) under the assumption that the user is overriding it. If we still have more than one plug-in, it's an error. Restructure the initialization subsystem to use the plug-in, doing all the proper assertions and what not. The IDatabase interface defines what the database back-end plugin must provide. I've no doubt this will eventually need a bit more fleshing out, but it gives all this stuff a principled hook point instead of something ad-hoc.