Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Bigint unsigned ids #7081
Please be sure you are submitting this against the staging branch.
We noticed that some of Mautic instances we manage has quite high autoincrements on statistical database tables already and we calculated that we have very few months until they overflow.
This PR changes all IDs to be INT UNSIGNED which will double the max INT limit. It also introduces new BIGINT UNSIGNED columns which are used on selected statistical tables.
I made a little research as I realized that PHP has limits on integers as well. It's defined by constant:
Note: 9223372036854775807 ~= 2^63
So what we are using now is fine and will work on 32 bit processors for the whole range. If we switch to
I consulted this with our team and we decided to switch to
This changes will appear on new installations only. This PR does not contain migrations of current tables on purpose. Those migrations would be massive as MySql will create a copy of the current stat tables to alter the column type. This can lead to big troubles during migrations of big-size databases such as run out of disk space or overloading database with incoming traffic while the tables are locked.
Not only ID columns will be affected by this change. Doctrine is more clever. It changes types also to all foreign key columns. So when I changed leads.id to BIGINT then all tables containing lead_id column will be re-typed too. So it will affect majority of the tables anyway.
If your instance is getting close to the INT limit then follow these steps to migrate:
Steps to reproduce the bug:
Steps to test this PR:
Yeah i meant it because of:
I thought we talked about it. But I feel confortable giving this responsibility to the release leader :D
Jan 14, 2019
If I call app/console doctrine:schema:update --dump-sql
The schema for new installations is generated from the Doctrine entities. In theory, users shouldn't need anything else to migrate from one version to another than the
That's what I was aiming for with this PR.
Sadly, in practice we sometimes need the
Ok, but I think the issue @kuzmany noted was not during --dump-sql but during execution of that SQL. When running such alterations you must run
Edit: I stand corrected, apparently the order of the alter statements also needs to be more specific than DBAL understands. Hmm.
I'd like to, but there is no conceivable way to make the
You have to to manually remove those foreign key constraints, then run the SQL, then recreate those foreign key constraints. Otherwise you get errors like this:
I'm running out of ideas on this :(
We have a method somewhere that generates the FK names the way Doctrine does so the
I plan to make this change for M3 which may be the best opportunity for this. Users may expect more tedious migration coming from M2 to M3.