-
-
Notifications
You must be signed in to change notification settings - Fork 188
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New Flow environment generates doctrine migrations #1521
Comments
Just for the records, here's the full output of the
The only migration that was not "green" in the output was 20150611154419 because of:
Looking into that migration file, this seems obvious and unrelated to my above mentioned issue (the migration updates database entries of file-resources in case they need to be moved + updated - which obviously is not the case in an empty database). |
Thanks for taking the time and effort to dig into this annoyance! |
I'm struggling with the same problem since I executed Migration 20180622074421, because it's not correct. The index In my opinion the following migration could be added to solve the issue: <?php
namespace Neos\Flow\Persistence\Doctrine\Migrations;
use Doctrine\DBAL\Migrations\AbstractMigration;
use Doctrine\DBAL\Schema\Schema;
class Version20190516092450 extends AbstractMigration
{
/**
* @return string
*/
public function getDescription()
{
return 'Fixed index in "sha1" column of the "resource" table';
}
/**
* @param Schema $schema
* @return void
*/
public function up(Schema $schema)
{
// this up() migration is autogenerated, please modify it to your needs
$this->abortIf($this->connection->getDatabasePlatform()->getName() != 'mysql', 'Migration can only be executed safely on "mysql".');
if (in_array('neos_flow_resourcemanagement_persistentresource', $this->sm->listTableNames())
&& array_key_exists(strtolower('IDX_35DC14F03332102A'), $this->sm->listTableIndexes('neos_flow_resourcemanagement_persistentresource'))) {
$this->addSql('DROP INDEX IDX_35DC14F03332102A ON neos_flow_resourcemanagement_persistentresource');
$this->addSql('CREATE INDEX IDX_6954B1F63332102A ON neos_flow_resourcemanagement_persistentresource (sha1)');
}
}
/**
* @param Schema $schema
* @return void
*/
public function down(Schema $schema)
{
// this down() migration is autogenerated, please modify it to your needs
$this->abortIf($this->connection->getDatabasePlatform()->getName() != 'mysql', 'Migration can only be executed safely on "mysql".');
if (in_array('neos_flow_resourcemanagement_persistentresource', $this->sm->listTableNames())
&& array_key_exists(strtolower('IDX_6954B1F63332102A'), $this->sm->listTableIndexes('neos_flow_resourcemanagement_persistentresource'))) {
$this->addSql('DROP INDEX IDX_6954B1F63332102A ON neos_flow_resourcemanagement_persistentresource');
$this->addSql('CREATE INDEX IDX_35DC14F03332102A ON neos_flow_resourcemanagement_persistentresource (sha1)');
}
}
} Because of the checks for table and index existence it would not affect projects where the owner has changed the index manually, but would help all others. |
(re-opening here as a new issue as I wasn't able to move the issue I opened in the wrong project, see neos/flow-development-distribution#37)
A Flow application where I add a new domain model or change an existing one and after that ran a
doctrine:migrationgenerate
command to generate the according migration always showed "additional" changes to the schema that were not related to my changes to the domain models. At first I thought $someoneElseOrMyself left over some dirty unfinished stuff - but we couldn't figure it out.The second time I've seen the issue was a fresh project - where it seemed unexpected that there is anything in a strange condition. The command always showed differences between the migrations and the actual DB schema.
Then I started playing with ddev to see if that fits my needs for a local dev environment - and again I saw this issue, with a fresh, empty database. At this point, also my thought of "well, maybe our MySQL config is not optimal for Flow/Neos" also vanished.
I've now stumbled over this annoyance the n-th time and finally took the time to dig deeper into it:
Steps to reproduce:
./flow doctrine:migrate
./flow doctrine:migrationgenerate
Expected behaviour:
Current behaviour:
doctrine:migrationgenerate
command detects changesThe text was updated successfully, but these errors were encountered: