Thanks for the history lesson!
A large part of me things that both "strings or objects" should be accepted
, this way there would be parity across the board. Because yes, it is
confusing!
But a larger part of me worries about backwards compatibility and
collisions. ForeignKey("mytable.id") could be referencing a table+column
or an object+attribute.
Maybe an ORM specific subclass could handle that -- e.g. `ORM` could have
it's own `ForeignKey` or `ForeignKeyDeclarative` that accepts object, not
table, data. Docs would push people to use the new ORM classes, instead of
the existing core ones.
This is, of course, just ideas for Sqlalchemy 2.0
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/groups/opt_out.
