On Aug 22, 2013, at 6:08 AM, Gerald Thibault <[email protected]> wrote:
> I looked into the AddConstraint class, and added some debugging info and > found it wasn't being hit, because the fk was part of a CREATE. So I'd need > to use @compiles to override both of those to ensure both of them render the > references correctly. > > The single point where the magic happens is in compiler.py, in a function > called 'define_constraint_remote_table'. Can I use @compiles to override that > function? > > Right now I have manually added the following to > dialects.mysql.base.MySQLDDLCompiler: > > def define_constraint_remote_table(self, constraint, table, preparer): > """Format the remote table clause of a CREATE CONSTRAINT clause. > If using InnoDB, tables without manually-provided schemas will > be formatted using the default connection schema when rendered > in foreign key statements. This is because InnoDB (or perhaps > mysql?) will interpret references without schemas as being in the > same schema as the table being created/altered """ > > engine_key = '%s_engine' % self.dialect.name > is_innodb = engine_key in table.kwargs and \ > table.kwargs[engine_key].lower() == 'innodb' > > if is_innodb and table.schema is None: > default_schema = table.bind.url.database > constraint_schema = constraint.columns[0].table.schema > if constraint_schema not in (default_schema, None): > """ if the constraint schema is not the default, we need to > add a schema before formatting the table """ > table.schema = default_schema > value = preparer.format_table(table) > table.schema = None > return value > return preparer.format_table(table) > > > This does exactly what I want it to, and ensures that in any cases where the > referenced keys are in a different schema than the active table, the keys are > prefixed by the schema. > > Is there a way to 'inject' this into the MySQLDDLCompiler? if you specify a "name" and "use_alter=True" on your ForeignKey it should use the AddConstraint feature, which is easier to override. > > Would this version of the formatting function not be more appropriate than > the current, as the current is unable to handle a simple 2 model relation > when they are in different schemas? first I'd want to fully understand and verify exactly what's going on with this, if you have some definitive documentation that refers to this it would be helpful. from there I'd probably still prefer to make this a table-level flag (I considered a dialect-level flag, but this is really part of "mysql_engine"'s behavior), particularly because we prefer CREATE TABLE statements to be correct for the target database even in the absence of a database connection.
signature.asc
Description: Message signed with OpenPGP using GPGMail
