I mean really, it might not be that hard to just get ForeignKey to accept a
callable, it just would have to be explicitly supported. the mechanics got
much more complicated when i got the whole “we use the type from the parent
column” thing to work 100%.
On Jan 13, 2014, at 3:46 PM, Michael
because the event is the public, stable API ;). I’d prefer the _set_parent()
is a no-op but at the moment there’s a NotImplementedError in there.
On Jan 13, 2014, at 3:22 PM, Alessandro Molina
wrote:
> Looks good, just one curiosity, is there a reason for using
> "after_parent_attach" even
Looks good, just one curiosity, is there a reason for using
"after_parent_attach"
event instead of directly using _set_parent to register the LazyForeignKey
for being resolved?
2014/1/13 Michael Bayer
>
> On Jan 13, 2014, at 1:19 PM, Alessandro Molina <
> alessandro.mol...@gmail.com> wrote:
>
>
On Jan 13, 2014, at 1:19 PM, Alessandro Molina
wrote:
> Just noticed that SQLAlchemy 0.9 broke a LazyForeignKey class that was
> provided by TurboGears tgext.pluggable to make possible to declare foreign
> keys to models not yet defined at the time the ForeignKey was declared.
>
> The main u
Just noticed that SQLAlchemy 0.9 broke a LazyForeignKey class that was
provided by TurboGears tgext.pluggable to make possible to declare foreign
keys to models not yet defined at the time the ForeignKey was declared.
The main use was something like:
class User(DeclarativeBase):
__tablename__
