Hi, I think you are right, messing with the metaclass for 4 columns is not really what i want :) Instead i will use your approach. Put those Columns in the function within the mixin along with all other functions and then call them within the column-definition.
Thanks for fast answer! Greetings, Daishy On 14 Dez., 02:06, Michael Bayer <[email protected]> wrote: > On Dec 13, 2009, at 12:09 PM, Daishy wrote: > > > Hi together, > > > I'm sorry if this is a rather stupid question, but i havent found a > > solution yet :/ > > I have a few models build with the DeclarativeBase-Class. Now each of > > these models has a few columns that they have in common (created_by, > > created_at, updated_by, updated_at). Rather than putting the code i > > need for these columns and the columns itself in each model, i wanted > > to put it into a seperate class and inherit from it (or include it). > > But if i query ModelA i just get '(no name)' if i print the created_X > > columns. Is there any way to extract columns each model should have > > into a seperat class? > > 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. > > 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. > > 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. 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"...). > > What I usually do is to reduce the overhead by creating callables for the > desired columns (usually the same created_at etc. columns you're using here): > > 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() > > The "metaclass subclass" approach is somewhere in the list archives if you > want to search for it. > > Also, it wouldn't be impossible for declarative to someday be enhanced to > accept "mixins", which probably would subclass a specific class to mark them, > and would be allowed to declare a limited set of "copyable" attributes, > namely Column objects and perhaps deferred()s also. I haven't tried > working out such a feature as of yet, however. > > > > > > > class Data: > > created_by = Column(Integer) > > created_at = Column(DateTime) > > > class ModelA(DeclarativeBase, Data): > > id = Column(Integer, primary_key=True) > > somethingelse = Column(Integer) > > > Thanks very much! > > Daishy > > > -- > > > You received this message because you are subscribed to the Google Groups > > "sqlalchemy" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group > > athttp://groups.google.com/group/sqlalchemy?hl=en. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
