I have a lot of tables that have some similar functionality that I would like to factor out into a base mix-in class that provides some common methods. Some of these methods will want to use a method that must be defined in the actual table ORM class, and would be an abstract method in the base. If you just blindly do this you get the Python error of multiple metaclasses, so I need to define a metaclass that inherets from both ABCMeta and DeclarativeMeta, and then the Table ORM classes need to mention declarative_base, the mixin and metaclass=mymeta. This works but looks wordy.
If instead I try to put the mix-in between declarative_base and the table class in the heirarchy, SQLAlchemy complains that it is missing information for it to be a table (which is correct). If I put it as a base to declarative_base the SQLAlchemy gets errors that it needs to implement the abstract methods (and I of course can only do this once). I could make the mixin not use the ABCMeta as its metaclass, but then if I forget to define the abstract method in the table, I get no complaints, at best I could catch the call to the abstract method because it wasn't overridden. Is this the way it is supposed to work, or am I missing some other trick? Side question, when doing this sort of mix-in, does the order of the mix-in and declarative_base matter, or is there a real preference? -- Richard Damon -- SQLAlchemy - The Python SQL Toolkit and Object Relational Mapper http://www.sqlalchemy.org/ To post example code, please provide an MCVE: Minimal, Complete, and Verifiable Example. See http://stackoverflow.com/help/mcve for a full description. --- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sqlalchemy/e8d4c401-95fe-957f-7d65-3e37cd5150c6%40Damon-Family.org.
