I have two migrations file and I want to execute the latest one, after show versions I got :
Latest Version:2019-10-01 13:23:06 (20191001132306)
and I execute :
php bin/console doctrine:migrations:migrate 20191001132306
symfony still execute the first one which have some errors, should I delete it or there a way to execute a specific migration file !!
you can delete the migration file and delete the record on your database from the table
migration_versions.
But I'd like to suggest to delete all migration.php files, delete * from migration_versions where 1 = 1 on the database and do again "diff", "migrate" from console.
Related
After creating an Entity and Repository from an existing pre-doctrine database, I am unable to make an initial migration. It gave me this error [ERROR] The version "latest" couldn't be reached, there are no registered migrations. Any idea how to do an initial migration without starting fresh? And for some reason, the migration folder exists outside the src folder, why is it so? In a previous project, the migration folder exists inside the src folder.
Any insight would be appreciated. Thank you for reading.
EDIT: doctrine_migrations.yaml:
doctrine_migrations:
migrations_paths:
# namespace is arbitrary but should be different from App\Migrations
# as migrations classes should NOT be autoloaded
'DoctrineMigrations': '%kernel.project_dir%/migrations'
The commands I used to generate the Entity and its Repository is as follows:
php bin/console doctrine:mapping:import "App\Entity" annotation --path=src/Entity
modified the #ORM\Entity => #ORM\Entity(repositoryClass="App\Repository\UserRepository") in the entity .php
php bin/console make:entity --regenerate
Then when I run bin/console doctrine:migrations:migrate, the error pops up.
Work for me
doctrine_migrations:
migrations_paths:
'App\Migrations': '%kernel.project_dir%/src/Migrations'
and use for migration classes
namespace App\Migrations;
THis is my migrations config.You can test it :
doctrine_migrations:
dir_name: '%kernel.project_dir%/src/Migrations'
# namespace is arbitrary but should be different from App\Migrations
# as migrations classes should NOT be autoloaded
namespace: DoctrineMigrations
For migration commande i use : php bin/console d:m:diff and after this you can use the migration number with this commande :
php bin/console d:m:e --up the_migration_number
I tried most of the methods but it seems that it is possible to generate the migration. However, changes to the entity will not be detected by doctrine.
For example, if I change the field of name to username, php bin/console doctrine:migration:diff does not detect the changes.
What I found worked was exporting the database as .sql, creating the entity the normal way, and manually typing in the fields. Delete the generated table in phpmyadmin, and importing the data back in. Only then would it be working as I want it to be.
I'm trying to update my database with those commands
php bin/console make:migration
this return success
But when I try
php bin/console doctrine:migrations:migrate
I have this error:
WARNING! You have 5 previously executed migrations in the database >>that are not registered migrations.
>> 2018-12-17 10:42:04 (20181217104204)
>> 2018-12-17 13:19:24 (20181217131924)
>> 2018-12-17 13:40:58 (20181217134058)
>> 2018-12-18 10:41:38 (20181218104138)
>> 2018-12-18 13:15:49 (20181218131549)
Thing is, the database listed here are not in my migrations table from my database and they are not in my Migrations folder either.
How can I remove those wrong migrations ? Thanks.
This is a year old, but I've had problems a few times where I delete old migration files because they aren't relevant or whatever reason and had the same issue. I think the correct way to handle this is to delete references from the table directly.
php bin/console doctrine:query:sql "delete from migration_versions where version = '2020181217104204'";
EDIT - newer versions of Symfony are now using a "doctrine_migration_versions" table.
php bin/console doctrine:query:sql "delete from doctrine_migration_versions where version = '2020181217104204'";
Etc..
Encounterd the same probleme : I had previously copied already executed migration to the newly created migration table (due to doctrine update).
Renaming all version names as follow saved the day : 20190408092436 --> DoctrineMigrations\Version20190408092436
Can Flyway be used to mix creation and migration scripts so that:
new installations run a schema creation script
existing installations run migration scripts, and never see the creation scripts of subsequent versions
?
E.g. given:
db/create/V1/V1__schema.sql
db/create/V2/V2__schema.sql
db/create/V3/V3__schema.sql
db/migration/V1/V1.1__migrateA.sql
db/migration/V2/V2.1__migrateB.sql
db/migration/V2/V2.2__migrateC.sql
An existing V1 installation would run the following to get to V3:
db/migration/V1/V1.1__migrateA.sql
db/migration/V2/V2.1__migrateB.sql
db/migration/V2/V2.2__migrateC.sql
It would never run the following, as these represent schema-only SQL produced by mysqldump:
db/create/V2/V2__schema.sql
db/create/V3/V3__schema.sql
A new V3 installation would run:
db/create/V3/V3__schema.sql
The above conflicts with the approach recommended by Upgrade scenario when using Flyway but is required as data is populated independently of the migration.
It looks like it should be possible to use flyway.locations to support this, but installations would always need to include the path to their creation script so that Flyway can see it.
The alternative appears to be to run the creation scripts outside of Flyway and set a baseline, but it would be nice if Flyway could manage everything.
In the end, I developed a tool to do this.
The tool has the latest schema in:
db/schema/schema.sql
and the migration scripts in:
db/migration/<version>/<version>.<sequence>__<JIRA issue>.sql
e.g.:
db/migration/V1/V1.1__JIRA-15.sql
db/migration/V2/V2.1__JIRA-12.sql
db/migration/V2/V2.2__JIRA-22.sql
db/migration/V3/V3.0__JIRA-34.sql
If the database has no tables, schema.sql is executed, and then flyway is baselined with the most recent version, as reported by Flyway's
MigrationInfoService.pending() method.
i.e. the last MigrationInfo element returned by pending() determines the version to pass to Flyway.setBaselineVersion() before invoking Flway.baseline()
e.g:
DbSupport support = DbSupportFactory.createDbSupport(connection, true);
Schema schema = support.getOriginalSchema();
if (schema.allTables().length == 0) {
Resource resource = new ClassPathResource("db/schema/schema.sql", getClass().getClassLoader());
SqlScript script = new SqlScript(resource.loadAsString("UTF-8"), support);
script.execute(support.getJdbcTemplate());
MigrationInfo[] pending = flyway.info().pending();
MigrationInfo version = pending.length > 0 ? pending[pending.length - 1] : null;
if (version != null) {
flyway.setBaselineVersion(version.getVersion());
flyway.setBaselineDescription(version.getDecription());
flyway.baseline();
}
}
This ensures that none of the migration scripts are invoked for newly created databases, but does mean that schema.sql must already contain all of the changes.
If the database has tables, but no Flyway information, it is baselined according to the detected schema version.
I get this error when I create a new module:
"Please upgrade your database: Run "bin/magento setup:upgrade" from the Magento root directory.
The following modules are outdated:
Sangeeta_Octan data: current version - none, required version - 0.0.1";i:1;s:1781:"#0
I searched on google and found no solution other than reinstalling Magento. Such as:
version has been changed from "2.0.0.0" to "2.0.0" during development,
so update tool can't recognize that "2.0.0.0" <= "2.0.0". Please,
re-install your application from scratch to get latest version. `
Do I have any options apart from reinstalling?
Change the setup_version of your module (Sangeeta_Octan) in
app/code/Sangeeta/Octan/etc/module.xml. Try a different version
name like setup_version="2.0.1" or setup_version="3.0.0"
Run bin/magento setup:upgrade
If that doesn't work, disable your module by changing your module name in app/etc/config.phpfrom Sangeeta_Octan => 1 to Sangeeta_Octan => 0. Then run bin/magento setup:upgrade
I hope below solution also solve your problem.
https://magento.stackexchange.com/questions/112293/mysql-error-and-possible-duplicates-running-bin-magento-setupupgrade-after-rena/112299#112299
in mysql find the table setup_module It will have 3 fields. Find the NULL values in data_version & have them match the schema_version
As an alternative, you can access your magento database and look at the table setup_module
You will see a list of all installed modules and you can manually set the schema/data version numbers here.
Delete the offending rows from the setup_module table (if they are there) and run the command bin/magento setup:upgrade from your Magento 2 root directory.
This is happens because of something wrong while running "bin/magento setup:upgrade" and the data_version in Module versions registry is null. It is loaded from DB, We can just proceed by manually changing it in db.
Go db via php myadmin and check "setup_module" table, the
data_version which are mentioned "null".
Login to Mysql database => then update table setup_module of the "data_version" column same as "schema_version"
I'm trying to generate entities from existing tables in database, I keep getting the same error in a particular entity, which is imported from a second database (or entity manager), but I re-created this table in main database to use the same entity manager and get the same error, so I'm lost about what is happening.
This are my commands to generate it:
php app/console doctrine:mapping:convert yml ./src/MyShop/ProductBundle/Resources/config/doctrine/metadata/orm --from-database --filter="Product" --em=mysecondaryem
(BTW, is there a way to force exact filter? I only need Product)
Which seems to be ok:
Processing entity "ProductSold"
Processing entity "Product"
Exporting "yml" mapping information to...
Then
php app/console doctrine:mapping:import MyShopProductBundle annotation --em=mysecondaryem
Which is weird, as it is logging information about all other tables existing in this db but it's only generating the corresponding to "Product" as filtered (only the files ProductSold.php and Product.php do really exist):
Importing mapping information from "mysecondaryem" entity manager
> writing C:\mysite\src\MyShop\ProductBundle/Entity/ProductSold.php
> writing C:\mysite\src\MyShop\ProductBundle/Entity/Family.php
> writing C:\mysite\src\MyShop\ProductBundle/Entity/Category.php
> writing C:\mysite\src\MyShop\ProductBundle/Entity/Item.php
> writing C:\mysite\src\MyShop\ProductBundle/Entity/Stock.php
> writing C:\mysite\src\MyShop\ProductBundle/Entity/Product.php
Then, in the third step, I get an error:
php app/console doctrine:generate:entities MyShopProductBundle --no-backup
Generating entities for bundle "MyShopProductBundle"
[RuntimeException]
Bundle "MyShopProductBundle" does not contain any mapped entities.
doctrine:generate:entities [--path="..."] [--no-backup] name
As I sayed, I tried omitting secondary entity manager (replicating tables in my first database) and I get the same error.
You've verified that C:\mysite\src\MyShop\ProductBundle/Entity/Product.php has been created, but have you also checked that it actually contains mapped entities ?
Ok, I found the error, I was missing --force parameter, first step command should be:
php app/console doctrine:mapping:convert yml ./src/MyShop/ProductBundle/Resources/config/doctrine/metadata/orm --from-database --force --filter="Product" --em=mysecondaryem