dialect specific options are prefixed with the dialect name,e.g.
"mysql_engine", so that they only take place for the dialect currently
interacting with the schema object. they are ignored by any dialect that does
not have that name.
On Thu, Sep 3, 2020, at 10:15 AM, Simon King wrote:
>
You'd have to wait for a response from Mike to be certain, but it
seems overwhelmingly likely to me that dialect-specific options will
always be ignored by other dialects. One of the strengths of
SQLAlchemy is that it makes it easier to write code that works against
multiple database dialects, so
Thanks Simon,
Just to be clear:
dialect-specific options end up in table.dialect_options:
>
> https://docs.sqlalchemy.org/en/13/core/metadata.html#sqlalchemy.schema.Table.dialect_options
> But different dialects seem to handle them in different ways.
Does this mean that it's not safe in
To be honest, I looked for documentation before I wrote my reply to
you, and couldn't find anything. I just know that I often use MySQL in
production but sqlite for tests, and sqlite never complained about the
mysql-specific options in the table args.
dialect-specific options end up in
Thank you, Simon.
Yes, __table_args__ is the only reason I’m creating separate modules.
Where do you see that arguments that don’t match the database dialect of
the engine get ignored? I looked at the source code for answering this
question myself, but couldn't find an answer to that question.
Is __table_args__ the only reason why you are creating separate
modules for the different databases? You can specify parameters for
different database dialects in __table_args__, and the ones that don't
match the current engine will be ignored. For example:
import sqlalchemy as sa
from
__table_args__ don't merge automatically right now for mixins so you would need
to use a __table_args__ function with @declared_attr and merge the constraints
manually. see
Hi all,
I need to create identical models (mapped classes) for several database
backends, e.g. MySQL and MSSQL, that take different __table_args__.
Thus, I've opted for created one base for each database backend defining
the __table_args__ (*base.py*), while using common mixins for defining
