Hi again,
I took the approach with creating a Mixin with 4 staticmethods and
call them in each of my models, which works quite good. But now i face
another, i think related, problem.
i get the following columns produced:
created_by_id = Column(Integer, ForeignKey('worker.id',
onupdate="cascade", ondelete="restrict"))
updated_by_id = Column(Integer, ForeignKey('worker.id',
onupdate="cascade", ondelete="restrict"))
created_by = relation('worker')
updated_by = relation('worker')
Now sqlalchemy is throwing an exception, because the join-conditions
are not clear. Ok, so i have to add a primaryjoin-expression on the
relations. But how?
They should be specified like relation('worker',
primaryjoin=worker.c.id==???.c.created_by_id), but in my Mixin-Class i
dont know what ??? is, because it changes depending on the class using
the mixin. I could specify a parameter for these two static methods,
but thats another step making things more complicated, so i want to
avoid that if possible. Any advice?
Thanks!
Daishy
On 17 Dez., 19:59, Chris Withers <ch...@simplistix.co.uk> wrote:
> (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.
