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
This install is largely unnecessary, and in case of imported db, would delete the just-imported database, replacing it with a blank DB.
It should be enough to just run magento's setup:install, when the tables in DB do not exist at all. Alternatively, when env.php does not exist.
Db status code 1, means that's there's some version mismatch on the modules. That's generally resolved by running composer install + setup:upgrade.
An actual setup:install will drop existing tables and replace them with empty. In case of DB import, this occurs after the dump was imported, so the imported data is lost.
The version mismatch can occur for many reasons, e.g. the dump was pulled from an environment on one branch, but a local at the moment is on another branch with different composer modules - that would already result in such a code status. It doen't require new reinstall.
I'd structure the db import like this:
check if env.php / db exists. If not, run a setup:install to generate env.php and get blank DB.
import db
setup:upgrade / (composer install as necessary, before that)
Similarly for a regular start.
I've had reports of CMA npm start resulting in database being overwritten with brand new Magento DB, when a migartion script had exceptions during setup:upgrade, for example(because someone committed a broken patch, etc)
Overall, setup:install should only run if there's nothing in the db / env.php is missing. It is not a fix for DB status 1.
The actual fix for that, is composer install / setup:upgrade / in some rare cases, manual fix of module versions in setup_module table in DB.
Example of version conflict - this can occur when the module version in the DB is higher than what is installed by composer, for example when module was upgraded at some point, and after that the module was rolled back - Magento doesn't fix its setup_module automatically, and keeps the high version in the DB table. However, deleting and reinstalling entire database to deal with such an issue is overkill.
A discrepancy in module versions will simply result in an exception when accessing the website in the browser, which will actually display which versions are off, and then it can be up to developer / team lead to fix the issue with DB.
The text was updated successfully, but these errors were encountered:
Currently,
migrate-db.js
, which is executed under anysetupMagento
run (both for import-db and regular start)It runs
setup:db:status
, and when the resulting code is 1, the following is triggered:This install is largely unnecessary, and in case of imported db, would delete the just-imported database, replacing it with a blank DB.
It should be enough to just run magento's setup:install, when the tables in DB do not exist at all. Alternatively, when env.php does not exist.
Db status code 1, means that's there's some version mismatch on the modules. That's generally resolved by running composer install + setup:upgrade.
An actual setup:install will drop existing tables and replace them with empty. In case of DB import, this occurs after the dump was imported, so the imported data is lost.
The version mismatch can occur for many reasons, e.g. the dump was pulled from an environment on one branch, but a local at the moment is on another branch with different composer modules - that would already result in such a code status. It doen't require new reinstall.
I'd structure the db import like this:
Similarly for a regular start.
I've had reports of CMA npm start resulting in database being overwritten with brand new Magento DB, when a migartion script had exceptions during setup:upgrade, for example(because someone committed a broken patch, etc)
Overall, setup:install should only run if there's nothing in the db / env.php is missing. It is not a fix for DB status 1.
The actual fix for that, is composer install / setup:upgrade / in some rare cases, manual fix of module versions in
setup_module
table in DB.Example of version conflict - this can occur when the module version in the DB is higher than what is installed by composer, for example when module was upgraded at some point, and after that the module was rolled back - Magento doesn't fix its
setup_module
automatically, and keeps the high version in the DB table. However, deleting and reinstalling entire database to deal with such an issue is overkill.A discrepancy in module versions will simply result in an exception when accessing the website in the browser, which will actually display which versions are off, and then it can be up to developer / team lead to fix the issue with DB.
The text was updated successfully, but these errors were encountered: