(sorry, missed this earlier) Michael Bayer wrote: > The Column objects you declare within declarative become members of > the underlying Table object, so its not as simple as just having > those members present on a mixin - what would really be needed would > be some sort of copying of each column object when declarative comes > across them.
Indeed, how about a marker on "abstract" base classes like the Django ORM? > The mechanism of declarative is also to look at the "dict" of only > the endpoint class itself when picking up the attributes to add to > the Table/mapper, so at the moment any mixin would be ignored in any > case. That's a shame, are there plans to change that approach and iterate over dir() of the endpoint class instead? > There is an alternative approach to the "place these columns on > every class" problem, which involves making a subclass of the > metaclass that adds the desired columns when a new class is created. What about the cls parameter to declarative_base? Someone on #sqlalchemy recommended that and linked to some working code: http://progetti.arstecnica.it/sol/browser/sol/model/base.py Is there a problem with having more than one Base in a project? > I don't prefer this method since we're usually talking about just a > few columns, the metaclass itself is slightly awkward, and at the > end of the day I do like to see the columns listed out on each class > (hence "declarative"...). Yeah, but duplicate typing is always bad... That's why python allows inheritance... > def created_at(): > return Column(DateTime, default=func.now) > > so you only need to add a little bit to each class: > > class Foo(Base): > ... > > created_at = created_at() > updated_at = updated_at() Yeah, I've used this approach too, but when it's several columns, and a few utility methods, a class really seems like the right (dare I say pythonic?) place for it to be? How about something like: class Foo(Base): __abstract__ = True ... ...which would provide the desired functionality here? > The "metaclass subclass" approach is somewhere in the list archives > if you want to search for it. Advising end users to write metaclasses is always bad in my books :-( (In fact, this all came up 'cos a colleague of mine was reaching for one of our python books, I asked why, she replied "to remind myself how metaclasses work", to which my reply was "you *never* want to do that" ;-) ) Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
