ORM layer transition

Hi Developers!
In honor of the penultimate Mailman Day of 2014, I wanted to announce a significant transition in the implementation of Mailman 3 and call out the contributions of two of our members.
For a long while now we've used Storm as the ORM layer in MM3. ORM, meaning "object relational mapper" is the chunk of code that translates between the persistent Python objects in a running MM3 system and the underlying SQL database. Storm was a good choice many years ago because it was a nice, simple, thin layer that was easy to understand, use, and customize.
In the intervening years though, Storm has shown its age. It is no longer effectively maintained upstream, and it does not support Python 3. While MM3 is not yet a Python 3 application, it is my strong desire to eventually make it so. The fact that Storm has no Python 3 port, and is unlikely to, would prevent MM3 from being ported[*].
In a survey of the alternative available standalone Python ORMs, SQLAlchemy stands out as popular, well-maintained, long stable, and Python 3 compatible, and thus I am happy to announce that the MM3 trunk has been ported to SQLAlchemy (SA). The full test suite completes against both SQLite and PostgreSQL as back-ends, and I would expect that with a little bit of work (contributions welcome!) any other back-end supported by SA should work too.
In addition, rather than the ball-of-hack I wrote to migrate the database schema from one version to another, we will now be using Alembic to manage schema migrations.
I must acknowledge two really spectacular contributions from our members.
Abhilash Raj began the SA port almost on a dare by me on IRC and with many discussions in various forums, produced the bulk of the port. He asked great questions, answered mine own with patience, showed good diligence, and the depth of knowledge about MM3 that such a port required. I have never met Abhilash in person but the quality of his work is impressive.
Aurélien Bompard also provided invaluable contributions to this branch. Some of you may recognize Aurélien from his work on Hyperkitty, the fabulous new archiver. Aurélien was able to join us last year at the Pycon sprint, and it was really great to be able to hang out with him. He did an incredible amount of testing and refinement on the SA branch, feeding me patches that fixed a few of the outstanding test failures, especially on PostgreSQL.
Without the contributions of both Abhilash and Aurélien, this port would not have happened. Kudos to them, and my personal appreciation for their patience and enthusiastic good spirits in working with their picky, curmudgeonly project leader, who took much too long to review and merge their work. :)
I encourage the adventurous among you to grab the bzr trunk and give it a whirl. Do let us know here or in the bug tracker about any problems you might encounter, especially if you are upgrading from an existing Storm-based instance of MM3.
At least one more release of the core is planned this year.
Enjoy, -Barry
[*] We have one other known Python 2-only dependency blocking our porting efforts. We use the restish library as our REST/HTTP framework, and while there are many things I love about restish, it falls into the same camp as Storm. It's Python 2-only, and effectively abandoned upstream. Fortunately we have a ready alternative in the Falcon framework. I have a branch of MM3 ported to Falcon ready to go as soon as upstream releases its new version, which will have a few changes I submitted that allows us to implement restish-style object-based traversal. This means we can port to Falcon, keep largely the same REST code in place, and be ready for Python 3.

Barry Warsaw writes:
I am happy to announce that the MM3 trunk has been ported to SQLAlchemy (SA). The full test suite completes against both SQLite and PostgreSQL as back-ends, and I would expect that with a little bit of work (contributions welcome!) any other back-end supported by SA should work too.
Huzzah! Happy Mailman Day! (Although it isn't here any more. :)
Without the contributions of both Abhilash and Aurélien, this port would not have happened. Kudos to them,
+1 !!
Steve

Hi,
First, thanks for this wonderful enhancement, it's gonna make a lot of things much easier and reliable! I've just tried the branch and wanted to point out that I had to add :
"from __future__ import print_function"
at the beginning of:
- src/mailman/bin/checkdbs.py
- src/mailman/bin/bumpdigests.py
otherwise it would complain about using "file=" in the print function (using python2.x).
It looks to run smoothly in my test environment, how crazy is it to try it on the production server? Any chance to corrupt the DB? :)
I'd like to explore the possibility to write a migration script from sqlite to postgres with the new ORM (saw this: https://zignar.net/2011/11/01/copy-data-from-mysql-to-postgres-using-sqlalch... ). If someone is already working on this, please tell me!
Cheers,
Guillaume
Le 01/11/2014 20:16, Stephen J. Turnbull a écrit :
Barry Warsaw writes:
I am happy to announce that the MM3 trunk has been ported to SQLAlchemy (SA). The full test suite completes against both SQLite and PostgreSQL as back-ends, and I would expect that with a little bit of work (contributions welcome!) any other back-end supported by SA should work too.
Huzzah! Happy Mailman Day! (Although it isn't here any more. :)
Without the contributions of both Abhilash and Aurélien, this port would not have happened. Kudos to them,
+1 !!
Steve
Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/glibersat%40sigil...
Security Policy: http://wiki.list.org/x/QIA9

Guillaume Libersat writes:
It looks to run smoothly in my test environment, how crazy is it to try it on the production server? Any chance to corrupt the DB? :)
Only you can judge craziness, but I would say, yes, there is a chance of DB corruption that is higher than before the migration. No reflection on anybody's work here, but different ORMs make slightly different assumptions about the workflow and interfaces. It's not easy to get all these things absolutely correct when migrating.
I don't think the risk is very high; if I were already running a production server with data I worried about (my server is production in a sense but it would be the work of 15 minutes to reproduce the subscriber list by hand :-), I'd just back up twice a day instead of once.

On Nov 03, 2014, at 10:59 PM, Guillaume Libersat wrote:
I've just tried the branch and wanted to point out that I had to add :
"from __future__ import print_function"
at the beginning of:
- src/mailman/bin/checkdbs.py
- src/mailman/bin/bumpdigests.py
otherwise it would complain about using "file=" in the print function (using python2.x).
Those two files haven't been ported to MM3 yet. I also haven't gotten around to deleting them. ;) Really they need to be changed into a subcommand of the 'mailman' cli. Contributions welcome!
I'd like to explore the possibility to write a migration script from sqlite to postgres with the new ORM (saw this: https://zignar.net/2011/11/01/copy-data-from-mysql-to-postgres-using-sqlalch... ). If someone is already working on this, please tell me!
Not that I know of but it would be a nice script to have. If you do come up with something let us know.
Cheers, -Barry
participants (3)
-
Barry Warsaw
-
Guillaume Libersat
-
Stephen J. Turnbull