DDC-1049: "Safe" database migrations #1307

Closed
opened 2026-01-22 13:09:40 +01:00 by admin · 4 comments
Owner

Originally created by @doctrinebot on GitHub (Feb 28, 2011).

Originally assigned to: @beberlei on GitHub.

Jira issue originally created by user jkleijn:

It would be nice if SchemaDiff was able to produce SQL that does not destroy data.

For the purpose of database migrations, SchemaDiff::toSaveSql() does not seems "safe". When I do a downgrade it still drops columns, and does not seem to check if the column contains values.

It does after all say "save" not "safe". The doccomment says:

"This way it is ensured that assets are deleted which might not be relevant to the metadata schema at all." -- not sure what is meant by this, but it is clear the author really did not mean "safe".

Perhaps it has something to do with statements not being properly ordered? Right now I have to do something like this:

$statements = array();
$indexdrops = array();

foreach($schemaDiff->toSql($conn->getDatabasePlatform()) as $sql)
{
if(preg_match('/DROP\sINDEX\s|DROP\sFOREIGN\sKEY\s+/', $sql)){
$indexdrops[] = $sql;
continue;
}

$statements[] = $sql;

}

$statements = array_merge($indexdrops, $statements);

foreach($statements as $sql)
{
$this->_log("DDL: $sql");
$conn->executeQuery($sql);
}

Seems hardly fool-proof.

But I digress. What I am asking for is a method, perhaps named "toDataSafeSql", which does not destroy data. Instead of dropping columns and tables, it could rename them by convention. For example:

$diff->toDataSafeSql($obsoletePrefix = 'obsolete**');

Which would prefix obsolete tables and columns instead of dropping them. This would be an important feature for anyone looking to do migrations with generated DDL.

Thanks.

Originally created by @doctrinebot on GitHub (Feb 28, 2011). Originally assigned to: @beberlei on GitHub. Jira issue originally created by user jkleijn: It would be nice if SchemaDiff was able to produce SQL that does not destroy data. For the purpose of database migrations, SchemaDiff::toSaveSql() does not seems "safe". When I do a downgrade it still drops columns, and does not seem to check if the column contains values. It does after all say "save" not "safe". The doccomment says: "This way it is ensured that assets are deleted which might not be relevant to the metadata schema at all." -- not sure what is meant by this, but it is clear the author really did not mean "safe". Perhaps it has something to do with statements not being properly ordered? Right now I have to do something like this: $statements = array(); $indexdrops = array(); foreach($schemaDiff->toSql($conn->getDatabasePlatform()) as $sql) { if(preg_match('/DROP\s<ins>INDEX\s</ins>|DROP\s<ins>FOREIGN\s</ins>KEY\s+/', $sql)){ $indexdrops[] = $sql; continue; } ``` $statements[] = $sql; ``` } $statements = array_merge($indexdrops, $statements); foreach($statements as $sql) { $this->_log("DDL: $sql"); $conn->executeQuery($sql); } Seems hardly fool-proof. But I digress. What I am asking for is a method, perhaps named "toDataSafeSql", which does not destroy data. Instead of dropping columns and tables, it could rename them by convention. For example: $diff->toDataSafeSql($obsoletePrefix = 'obsolete**'); Which would prefix obsolete tables and columns instead of dropping them. This would be an important feature for anyone looking to do migrations with generated DDL. Thanks.
admin added the Improvement label 2026-01-22 13:09:40 +01:00
admin closed this issue 2026-01-22 13:09:40 +01:00
Author
Owner

@doctrinebot commented on GitHub (Feb 28, 2011):

Comment created by @beberlei:

You can just implement this yourself, there is a Visitor interface for Schema and you can also just take the SchemaDiff output from Doctrine\DBAL\Schema\Comparator. This won't be put into the core though. Handling Schema / Database migrations is a pretty complicated task and I could think of 100 strategies to do it but i dont want to support them all. SchemaTool is for convenenience in development, nothing else. If the migrations get messy you should do it yourself anyways.

@doctrinebot commented on GitHub (Feb 28, 2011): Comment created by @beberlei: You can just implement this yourself, there is a Visitor interface for Schema and you can also just take the SchemaDiff output from Doctrine\DBAL\Schema\Comparator. This won't be put into the core though. Handling Schema / Database migrations is a pretty complicated task and I could think of 100 strategies to do it but i dont want to support them all. SchemaTool is for convenenience in development, nothing else. If the migrations get messy you should do it yourself anyways.
Author
Owner

@doctrinebot commented on GitHub (Feb 28, 2011):

Issue was closed with resolution "Won't Fix"

@doctrinebot commented on GitHub (Feb 28, 2011): Issue was closed with resolution "Won't Fix"
Author
Owner

@doctrinebot commented on GitHub (Feb 28, 2011):

Comment created by jkleijn:

I'm not completely insensitive for your arguments, I guess I could adjust the diff for this purpose by the migration infrastructure.

What about the DDL order? toSql() produces statements in an order that is not executable.

@doctrinebot commented on GitHub (Feb 28, 2011): Comment created by jkleijn: I'm not completely insensitive for your arguments, I guess I could adjust the diff for this purpose by the migration infrastructure. What about the DDL order? toSql() produces statements in an order that is not executable.
Author
Owner

@doctrinebot commented on GitHub (Feb 28, 2011):

Comment created by @beberlei:

That is a bug, can you file a new issue in DBAL for this?

@doctrinebot commented on GitHub (Feb 28, 2011): Comment created by @beberlei: That is a bug, can you file a new issue in DBAL for this?
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#1307