You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is possible to have a foreign key that points to a table in a different database (albeit not common?). In this case, the drop foreign key will fail, as the query looks for key usage in "DATABASE()". See snippet below from MysqlAdapter about line 898.
I think, but am not sure, that you could modify the WHERE condition to IS NOT NULL? For context, I have an employees database that is separate from an application database. The application database references employees in that employees DB. The workaround for me would be to create a view. So, I would not consider this a high priority issue, but one you may want to know about. The juice might not be worth the squeeze, so to speak.
foreach ($columns as $column) {
$rows = $this->fetchAll(sprintf(
"SELECT
CONSTRAINT_NAME
FROM information_schema.KEY_COLUMN_USAGE
WHERE REFERENCED_TABLE_SCHEMA = DATABASE()
AND REFERENCED_TABLE_NAME IS NOT NULL
AND TABLE_NAME = '%s'
AND COLUMN_NAME = '%s'
ORDER BY POSITION_IN_UNIQUE_CONSTRAINT",
$tableName,
$column
));
foreach ($rows as $row) {
$instructions->merge($this->getDropForeignKeyInstructions($tableName, $row['CONSTRAINT_NAME']));
}
}
The text was updated successfully, but these errors were encountered:
I don't think phinx allows interacting with databases outside of the database specified in the connection. Based on what I've seen it doesn't handle databases or schemas through migrations unless we use raw SQL. This would be a great feature tho
It is possible to have a foreign key that points to a table in a different database (albeit not common?). In this case, the drop foreign key will fail, as the query looks for key usage in "DATABASE()". See snippet below from MysqlAdapter about line 898.
I think, but am not sure, that you could modify the WHERE condition to IS NOT NULL? For context, I have an employees database that is separate from an application database. The application database references employees in that employees DB. The workaround for me would be to create a view. So, I would not consider this a high priority issue, but one you may want to know about. The juice might not be worth the squeeze, so to speak.
The text was updated successfully, but these errors were encountered: