ated. i'll look at using INFO and DEBUG
> tomorrow to get a better idea of what's going on, but using public as my
> dev schema to autogenerate against works. i just have to exclude the
> alembic tables.
>
> again thanks for your help in understanding what i was trying to do.
>
> brian
t;>>
>>>>> # set alembic version table location in DB_SCHEMA
>>>>> context.configure(
>>>>> connection=connection,
>>>>> include_schemas=True,
>>>>> target_metadata=metadata,
>>>>> version_table_sc
y what
> tables it is reflecting.
>
>
> same behavior, entire schema generated. i'll look at using INFO and DEBUG
> tomorrow to get a better idea of what's going on, but using public as my
> dev schema to autogenerate against works. i just have to exclude the
> alembic t
):
>>> context.run_migrations()
>>>
>>>
>>
>>
>> no, don't use "include_schemas". you want to run alembic in a mode where it
>> has no idea there are other schemas to use. i think version_table_schema is
>> OK here but don't use inclu
what
> tables it is reflecting.
>
same behavior, entire schema generated. i'll look at using INFO and DEBUG
tomorrow to get a better idea of what's going on, but using public as my
dev schema to autogenerate against works. i just have to exclude the
alembic tables.
again thanks for your help in understanding
_path to {DB_SCHEMA}")
>
> # set alembic version table location in DB_SCHEMA
> context.configure(
> connection=connection,
> include_schemas=True,
> target_metadata=metadata,
> version_table_schema=DB_SCHEMA,
> )
>
> with context.begin_transaction():
> context.run_mi
t;. you want to run alembic in a mode where it has
no idea there are other schemas to use. i think version_table_schema is OK here
but don't use include_schemas. Also turn on INFO or DEBUG logging for the
sqlalchemy logger to see exactly what tables it is reflecting.
>
>
>
>
>
On Thursday, March 19, 2020 at 5:37:38 PM UTC-4, Mike Bayer wrote:
>
>
>
> On Thu, Mar 19, 2020, at 5:30 PM, Brian Hill wrote:
>
> Are there known issues with using autogenerate with multi-tenant
> (schema_translate_map)?
>
>
> it's complicated and not one-size-fits-al
:
>>
>>
>> On Thu, Mar 19, 2020, at 5:30 PM, Brian Hill wrote:
>>> Are there known issues with using autogenerate with multi-tenant
>>> (schema_translate_map)?
>>
>> it's complicated and not one-size-fits-all, if you consider that to be an
>> is
Here's my env.py. Thanks for the help.
Brian
On Thursday, March 19, 2020 at 5:37:38 PM UTC-4, Mike Bayer wrote:
>
>
>
> On Thu, Mar 19, 2020, at 5:30 PM, Brian Hill wrote:
>
> Are there known issues with using autogenerate with multi-tenant
> (schema_translate_map)?
&
On Thu, Mar 19, 2020, at 5:30 PM, Brian Hill wrote:
> Are there known issues with using autogenerate with multi-tenant
> (schema_translate_map)?
it's complicated and not one-size-fits-all, if you consider that to be an issue
>
> My metadata doesn't have a sch
Are there known issues with using autogenerate with multi-tenant
(schema_translate_map)?
My metadata doesn't have a schema and I my
schema_translate_map={None:'my_schema'}.
This works for migrations but when I use autogenerate the generated
revision file is the full schema and not the diff
12 matches
Mail list logo
