Is there a way that I can mark a Doctrine migration as "ran" or "executed" in the way that it won't be shown as a migration that needs to be migrated?
app/console doctrine:migrations:migrate --add Version20140409203042
I don't see anything in the --help.
The reason for doing this is my DB is up to date and imported from elsewhere, but this migration is asking to be ran every time I run a doctrine:migrations:migrate.
I found that this functionality falls under the version command:
Use this command to add a single version:
Symfony 2/3
app/console doctrine:migrations:version 20140430223207 --add
Symfony 4
bin/console --env=staging doctrine:migrations:version 'Application\Migrations\Version20220803073040' --add
Use this command to add them all:
app/console doctrine:migrations:version --add --all
In your database is table where stored doctrine migrations. You can just add line with version id (20140409203042). Default name of this table is migration_versions, i think, or you can find name in config (http://symfony.com/doc/current/bundles/DoctrineMigrationsBundle/index.html)
It is one possible solutions for doing migrations wihout running it. But you really should control all queries, if it ok. If one, or more are missing, you should do migrations with queries commented out.
In newer versions of doctrine the migration version name contains a namespace (Skipping Migrations)
Now the command may look like this:
bin/console doctrine:migrations:version 'DoctrineMigrations\Version20220407777666' --add
Related
I get this message in red box when I try to run php bin/console doctrine:schema:validate or php bin/console doctrine:schema:update -f:
"Feature was deprecated in doctrine/dbal 2.x and is not supported by installed doctrine/dbal:3.x, please see the doctrine/deprecations logs for new alternative approaches."
Symfony 5.3.12
Doctrine 2.7.1-DEV
Any ideas where and what I should search for this message? Thank you!
I guess these commands were deprecated because of the idea that all schema changes should go through migrations and so - be represented in code and be reviewed before execution. The old approach could not guarantee that data wouldn't be lost (as many of schema:update manipulations allowed removing column and creating a new one to rename it without migrating the values).
The better approach to update DB schema is using maker bundle and migration mechanism.
composer require symfony/maker-bundle --dev
composer require doctrine/doctrine-migrations-bundle
bin/cosnole make:migration will generate migration based on differences of schema in code (annotations, xml or yml) and a current DB schema.
bin/console doctrine:migrations:migrate will execute migration.
As a result you will get same thing as by running bin/console doctrine:schema:update -f.
I was running Symfony 4.4.8, and I wanted to update my project. So I ran:
composer update
It did automatically update the DoctrineMigrationsBundle (https://packagist.org/packages/doctrine/doctrine-migrations-bundle) from 2.1.2 to 3.0.1.
Composer failed at first because doctrine_migrations.yaml was not compatible with the DoctrineMigrationsBundle 3.0.1, so I ran:
composer recipes:install --force -v
composer install
But: it appears that the DoctrineMigrationsBundle v 3 has a totally different configuration and does not use the "migrations_versions" SQL table anymore, but a new "doctrine_migrations_versions"-table and a new migrations directory ('%kernel.project_dir%/migrations' instead of '%kernel.project_dir%/src/Migrations').
This means that every time you do:
php bin/console doctrine:migrations:diff
You will get in the migration:
$this->addSql('DROP TABLE migration_versions');
I read at https://symfony.com/doc/master/bundles/DoctrineMigrationsBundle/index.html that you can set the table name in doctrine_migrations.yaml manually like this:
doctrine_migrations:
storage:
table_storage:
'table_name': 'doctrine_migrations'
But that is of no use, because the v 3 table has an extra column "execution_time" and in the "version" column a namespace is prepended (e.g. "DoctrineMigrations\Version20200702112735.php"). So both tables are incompatible.
I can't find any information anywhere on properly upgrading DoctrineMigrationsBundle from v2 to v3.
I must say I am surprised by this, I thought that "composer update" was to be safe. Appearently, one of the symfony bundles didn't add a version limit automatically where it should if an upgrade is not possible.
So what should I do? Should I just let composer downgrade the DoctrineMigrationsBundle again? Or is there some way to get an upgrade of DoctrineMigrationsBundle from v2 to v3 to work after all?
I think everything is explained here: https://github.com/doctrine/migrations/blob/master/UPGRADE.md
If you have already update the bundle config, just run that command:
bin/console doctrine:migrations:sync-metadata-storage
It should work.
I am in development mode (APP_ENV=dev in .env), and everytime I change entities and run the 'make:migration' command, it returns me that there is no database changes.
After I run the 'cache:clear' command, it takes the changes into account and makes the migration file.
It's quite annoying. Do you have any idea from where it could come ?
I use the 'symfony server:start' to run the dev server, maybe it comes from here ?
If this is an annotation cache from a bundle that causing the issue, simple cache:clear might not help. Did you try do run doctrine:migration:diff?
You can also try to use --flush with your commands:
php bin/console doctrine:cache:clear-query --env=dev --flush
php bin/console doctrine:cache:clear-result --env=dev --flush
php bin/console doctrine:cache:clear-metadata --env=dev --flush
Update after comments:
What I meant, the complete way you use to deploy the entity changes.
As per Symfony 4, an entity update flow might look like below:
Update your entity class - your php/annotation changes
Clearing ALL Metadata cache entries
php bin/console doctrine:cache:clear-metadata
Generate a migration by comparing your current database to your mapping information.
php bin/console doctrine:migrations:diff
View the status of a set of migrations
php bin/console doctrine:migrations:status
Deploy migration
php bin/console doctrine:migrations:migrate --all-or-nothing
using option --all-or-nothing multiple migrations ran at the same time will be wrapped in a single transaction.
If one migration fails, all migrations will be rolled back.
More about migrations from official source: https://symfony.com/doc/master/bundles/DoctrineMigrationsBundle/index.html
Similar problem explained also here: Update an entity in Symfony 4?
Hope this will help and fix your issue.
I'm using Doctrine Migrations and all migrations worked nice until now.
The last one I've created is not recognized on the staging server, but it works perfect on my local machine.
The bundle recognizes as the latest migration the version 20151006091137, but it should be 20151011132851.
As you can see in the image the migration file exists on the server.
On my local machine Doctrine sees correctly the latest version.
Does anyone has any idea?
check into the table
doctrine_migrations
if your versionMigrations entry exist.
clear the cache
app/console doctrine:cache:clear-metadata
check if your entities is sync to database
app/console doctrine:schema:validate
add new migration and you shouldn't have any addSql()
app/console doctrine:migrations:diff
Sync your migrations to database
app/console doctrine:migrations:migrate -y
I am using Symfony 2.0 beta3 and I am facing a rather strange problem. I have
set up the ORM with a sqlite database following the instructions of
the website but when I type:
php app/console doctrine:database:create
then
php app/console doctrine:schema:create
and finally
php app/console doctrine:schema:update --force
I don't get any error (for example last command outputs "Database
schema updated successfully") but nothing is actually inserted into
the database. The table aren't even created. The database file is
generated after the first command but remains empty.
Since I have configured FOS_UserBundle I should have for example a
table fos_user…
When I type
php app/console doctrine:schema:update --dump-sql
It shows that three SQL requests are pending… If I execute these three requests using
SQLiteManager, it works (so the fos_user table is created)
but when I want to create a user using:
php app/console fos:user:create
I get a "SQLSTATE[HY000]: General error: 1 no such table: fos_user " error.
Why am I not given some error message when I run the first three
commands? Am I missing something?
I face the same behaviour using pdo_pgsql driver, except that the SQL
generated by the dump is not ANSI compliant so it can't be executed
for postgresql (use of datetime and autoincrement instead of timestamp
and serial)….
Any help would be much appreciated
I found this solution on the Symfony forums.
It would seem the helpers aren't creating two things that you need for the sqlite implementation to work correctly.
Firstly, in the parameters.ini for the project (tweak to suit):
database_path=%kernel.root_dir%/config/MyDatabase.db
Secondly, in the config.yml file in the doctrine.dbal section, add the following:
path: %database_path%
Then run:
php app/console doctrine:database:create
and it should generate the database for you in the app/config folder.
You will need to run:
php app/console doctrine:schema:create
to create the schema. Re-run the code that didn't work and it should work fine.
The FOSUserBundle is developed in sync to the symfony master.
Be sure to updated both, symfony and the FOSUserBundle.
Drop the schema (php app/console doctrine:schema:drop --force)
Manually check the db whether the schema is dropped. Otherwise do it per hand.
Clear the cache and ensure that it is writeable.
Run php app/console doctrine:schema:update --force again.