but note that you can have the FOREIGN KEY in your database and not
have the ForeignKey object in Python. In your alembic migration you
can use ForeignKey within op.create_table() and that part will
actually work, because it works around there being no other table
around. But on the autogenerate
On Fri, Apr 13, 2018 at 5:54 PM, Ashu Goel wrote:
> Err why would I do #3? This is a just a simple reproduction of my actual
> problem, in which the tables are obviously more fleshed out, and I would
> actually want to enforce that the value referenced in the foreign key
Err why would I do #3? This is a just a simple reproduction of my actual
problem, in which the tables are obviously more fleshed out, and I would
actually want to enforce that the value referenced in the foreign key
column actually existed in the foreign table. Am I missing something?
I'm fine
On Fri, Apr 13, 2018 at 5:11 PM, Ashu Goel wrote:
> Hey there,
>
> I am trying to setup a multi-schema database, where each schema has it's own
> metadata and tables, but ForeignKey constraints are allowed to cross
> schemas. This usually works fine until I start introducing
Hey there,
I am trying to setup a multi-schema database, where each schema has it's
own metadata and tables, but ForeignKey constraints are allowed to cross
schemas. This usually works fine until I start introducing something like
alembic revision autogeneration, which uses the sorted_tables
On Thu, Apr 12, 2018 at 08:25:06PM -0400, Mike Bayer wrote:
> try sending me a long a full POC and Ill try to play with it, any
yep I'll do it ..! I miss some time for now.. but it's definitively on
my todo list. I don't think I have an overly complicated use case, it's
just that I pay a lot of