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
Unable to pass DB migrations: Table 'point_groups' already exists #12993
Comments
@patrykgruszka could you please take a look? It seems that it's coming from |
It looks like this migration has failed to create the foreign keys. I'm afraid I don't know why, because the error occurred in the previous run and it's not in the log you posted. @uhlhosting you can add the missing keys manually:
@escopecz I wonder how could we avoid a problems like this, when migrations are partially executed. Maybe we could execute each query conditionally, but I'm not sure that's a good approach. |
We've added the Another approach is to split the alter tables into multiple migrations. |
Thanks for the follow up, I have made some attempts in past to recover from that, It could be maybe useful for me to know why I cannot apply the remaining upgrades. right now I got this: https://bin.uhl.cloud/?a21fbb0795b63b3c#2szrGX82hnEHdJPX1qD7ChQ9Z1SGi3uVfmUZ7e9wAmum Anyhow I tried running first CLI in MYSQL, got:
I still do not know for certainty how to apply all migrations and be up to date from this point on. Any advice is welcomed. |
@uhlhosting can you confirm that you've run the migrations once, it failed on something and then when you run it again this error happens? If so, what was the first error? |
It is all explained in this issue. All previous and current status and errors. Check the bin link please. |
I the bin link you are trying to execute a specific migration and it's replying it doesn't exist. Try to run it with
Then you are checking status, listing migration commands and executing migrations that are all passing. I think you are good to go! Or is Mautic erroring out on something? Don't worry about the migration status. Are you looking at the "New" count or what's the issue? |
We are experiencing a similar issue when trying to upgrade from 4.4.10 to 5.0.1 PHP Version 8.0.30
|
This issue has been mentioned on Mautic Forums. There might be relevant details there: https://forum.mautic.org/t/how-to-update-5-to-5-0-1-via-composer/30430/7 |
The migration fix is ready to test in #13195 |
Awesome, thanks @patrykgruszka - @uhlhosting @SayHeyD please can you review the fix in #13195 and leave a review as documented here: https://contribute.mautic.org/contributing-to-mautic/tester#leaving-your-review so we can get this merged and released asap? Many thanks for reporting & helping with troubleshooting! |
This issue has been mentioned on Mautic Forums. There might be relevant details there: https://forum.mautic.org/t/mautic-upgrade-to-4-4-10-5-0-1-breaks/30440/2 |
Ran into the same issue as mentioned here, trying to update Mautic 5.0.0-alpha1 to 5.0.1.
After applying patch #13195 migration/update has worked.
Thanks for the patch! Note: Users not able to manually apply the match should probably wait until 5.0.2 is released. |
Thank you for the info. Could you leave a review comment in #13195? It will help us merge this faster. |
Hi, this is the result:
only confusion starts here when i rerun migrate:
then again when I run :status:
|
The bottom line, is no matter if I run succesfully composer update / upgrade my Mautic does not bumps the version. My migration tables are clearly damaged or have some issues in a way or another, id appreciate if we can work this out. Why is next migration one from 2022, and why. 9 more shows are missing, and then they are skipped at migration process.
|
@uhlhosting is this with the changes in #13195? We'll be releasing Mautic 5.0.2 today if you don't know how to apply the change. I can see that the info in the migration:status command is confusing. But what is the actual issue? What is the error you cannot upgrade? I don't see any error in the last 2 comments from you. If you want to dig deeper into the specific migrations, check the files. For example: https://github.com/mautic/mautic/blob/5.x/app/migrations/Version20220722074516.php It may not be executed because your schema already contains the change. |
@escopecz hi I tried at first my own attempts to manually run the commands inside the migration against the db. What ever happened the instance seems stuck. And not sure what to do to allow the instance to upgrade the db. |
Stuck how? What is the error? Can you check the logs? |
The error is above, nothing else. this is what happends when I run migrate:
|
I'm confused. I don't see the error |
I got it now, You do miss the part that this is there because I added it manually, not the change itself. Hope this helps, was above described, must have missed it. I did my best to explain the situation, hope this time, someone will see what I try too hard by now to explain. |
@uhlhosting please try to be supportive to all people who try to help you with your issue. They are doing it for free in their free time and the only intention is to help you. Please, consider that. Perhaps summarize your current state into one comment would be a good way forward. And to be honest, I'm also confused. You say that you are getting an error from "above" yet output of the same command has changed in the following comments and the original error is gone. So I'm sorry, I do not understand what error are we solving now.
What have you done manually? I'm searching for "manually" in this issue and cannot find anything that you described you've done manually. Just so you'd understand how the migrations work; there is always a pre-check whether the migration should run or if the change that the migration is suppose to be making is already in place. All the messages in #12993 (comment) are saying that the pre-check found that the migration does not have to run because the change is already there. That's all. It's not an error. It's an information. Please, ignore it. So again, what error are you having? |
@escopecz there are no errors beside the fact that migration of DBs never fully completes as explained above.
This is an error to me. I cannot bypass it no matter what actions I did, and is al related to this single issue overall aand me trying to fix it ofcourse. |
And any guide on how to bring my database to date. Would be really appreciated. As of now I am stuck at alpha version. And cant seem to upgrade to stable release. |
Hi. I have the same error after update from 4.4.11 to 5.0.2. Site works, but migrations cannot be finished: Migrations with migrate:
Only the 20230621074925 --down
Only the 20230621074925 --up
Again only the 20230621074925 --up
Site runs: |
Might it have something to do with "prefixes"? My tables have prefixes and I am not sure if this is respected in the migration.
|
I also tried asking ChatGPT (sorry! not sorry)
Just trying! |
@escopecz any idea as to what could keep the dbs from upgrading and passing the DB changes from the new upgrade? |
Table leads: Table point_group_contact_score: Table point_groups: Shouldn't leads->id and contact->id be of same type? |
I can confirm this. I had the same issue. I commented out this line: |
I changed the data type in the column "contact_id" (table: mau_point_group_contact_score) from BIGINT(20) UNSIGNED to INT(11) and saved it. Then I created the foreign key in contact_id and was able to link to the column "id" in the table "leads". So, my migration has now manually finished, thanks @christopheg! |
When I delete the table point_group_contact_score (it is empty for me), the migration scripts recreate it, but still the type of contact_id is wrong. I think a "manual change auf column type" is not the right solution. Will there be a fix in the database schema? |
I'm not stating that my solution is good. It is a fix that could help people with a broken upgrade. A proper fix in the migration needs to be created by one of the developers. |
@patrykgruszka could you please take another look? The thing is that Mautic instances created before Mautic 3 were using INT signed for contact IDs and after M3 it was changed to BIGING unsigned as it should be. We are dealing with it in our migrations like this: $leadsTableName = $this->getPrefixedTableName('leads');
$contactTable = $schema->getTable($leadsTableName);
$contactIdColumn = $contactTable->getColumn('id');
$contactIdType = $contactIdColumn->getType() instanceof BigIntType ? 'BIGINT UNSIGNED' : 'INT'; And then in the CREATE TABLE statement we use the right type for the database: |
@escopecz : As far as I can see, this was not taken into account in this migration. See here:
If I understand your code correctly, you look at the type of the 'id' column in 'leads' to see what type it is and then use the same type to make any new table. |
@christopheg it's not that simple. If you change the type in the With M6 the installation will probably be just through Composer so users will have to switch to the new schema along the migration to Composer so that should fix that. |
@escopecz any ideas how I can push my mautic to fix the upgrade of DBs and pass the above explained error? |
If you mean this error: #12993 (comment) then it's not an error. It's just an information. Don't worry about it. If you need to learn more, then Mautic installs database schema from the Doctrine entities directly. But a migration is created for the users that are upgrading from previous versions. So there are some migrations that your Mautic installation does not need because the change was already present when you installed Mautic. So the "error" you are referring to is just an information that some migrations will not execute because the changes are already there. If you think this is way too confusing then please sponsor a developer to hide them somehow. This doesn't get priority from me as there are millions of more pressing issues that need attention. If you still have another problem then please create a new issue for this. I'm confused with the comments above. I believe the original error has been fixed and released so I'm closing this issue. |
|
But we still have an issue here, since the db field types don't match, this could lead to future problems. Fixing a foreign key of unsigned pointing to signed int is not just an optional migrition, I think. This not only happens on migration, but also when you delete the (for me) empty tables and let mautic recreate it. |
This issue was reporting this error: |
OK |
@escopecz what you refused to see again is that if it is all alright, tell me why my Mautic shows the version prior to upgrade in the UI, not the newer one that according to you I should ignore the ERROR message, yet to me something is fishy since I cannot see the new release I supposedly just upgraded to. Isn't that a bit of an issue? See composer results bellow from upgrade/update:
It says clearly 9 new migrations are not made. While the website shows: Again, I am even more confused how you can affirm with such ease that the errors can be ignored when the website and all the results shown shows the opposite! |
Since you fixed the issue I first reported yes, I accept, yet the fact that my mautic is stuck between versions is also due to very same issue. |
And not to mentioned I already posted the order of the migrations is scarry what does 2022 as Next?
|
@uhlhosting I repeat, please, open a new GH issue for your problem. The original problem is solved. This is very hard to navigate. The Mautic version is not stored in the database but in a file, so the database migration info messages you call "errors" cannot be to blame. Create a new GH issue, please where you describe how have you installed Mautic and what steps you did to update it. |
Mautic Version
5.0.x series
PHP version
8.1.26
What browsers are you seeing the problem on?
Not relevant
What happened?
Unable to pass DB migrations
How can we reproduce this issue?
Step 1: php bin/console doctrine:migration:migrate
Relevant log output
Code of Conduct
The text was updated successfully, but these errors were encountered: