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

MariaDB 10.2 initial support #2825

Merged
merged 45 commits into from Nov 19, 2017

Conversation

@belgattitude
Contributor

belgattitude commented Aug 26, 2017

Initial support for MariaDB 10.2.7+.

Doctrine currently does not support MariaDB 10.2.7+. Schema creation/update is triggering infinite schema diffs

Updated: Title updated from 'MariaDB 10.2 support (will also fix version detection), version detection should be considered as new feature.

Features

  • 1. MariaDb version detection (strip '5.5.5-' prefix)

To circumvent a limitation in the replication protocol, MariaDB 10+
use a prefixed version with '5.5.5-' (for instance 5.5.5-Mariadb-10.0.8-xenial).
This cause issues with the current detection mechanism with both Mysqli and PDOMysql
dbal implementations (always detect 5.5.5). While mariadb strips the prefix
automatically in their libmariadb-client, most (if not all) of php installations
relies on mysqlnd, so the removal of the prefix 5.5.5- must be made
in userland (MysqliConnection.php and AbstractMySQLDriver.php).
See https://jira.mariadb.org/browse/MDEV-4088 for reference.

  • 2. MariaDb 10.2 support BLOB/TEXT defaults values (since 10.2.1).

Update: Removed from this P/R... will be made available in a subsequent P/R (due to architecture decision to be made - current doctrine implementation needs to be reworked)

Note that Mysql (as of 5.7.19) is not yet supporting defaults for BLOB and TEXT.
See https://mariadb.com/kb/en/library/blob-and-text-data-types

  • UPDATED 3. MariaDb 10.2 support JSON type.

Removed from P/R by @lcobucci, probably to reflect the fact that MariaDB alias JSON to MEDIUMTEXT

The JSON type have been introduced in 10.2.7 as an alias to LONGTEXT.
See https://mariadb.com/kb/en/library/json-data-type/
To ensure portability between MySQL/Mariadb, the best is to prefer TEXT type over JSON when defining schema (till a real JSON type appears in Maria).

  • 4. MariaDb 10.2 supports CURRENT_TIME, CURRENT_DATE as default values

Note that MySQL (as of 5.7.19) does not support default values CURRENT_TIME and
CURRENT_DATE as default values for TIME and DATE columns (CURRENT_TIMESTAMP
for DATETIME is supported).

  • 5. Default literal values must be escaped.

Update: Removed from this PR in favor of #2850... Current doctrine implementation does not handle escaping of defaults (backslashes...), adding it in this P/R should be done for all platforms at once and thus introduce more BC-risks (bugs...). Implementing separately looks safer and should help having this P/R sooner. Both P/R can be done independently.

While table comments are automatically quoted (MySQLPlatform::quoteStringLiteral()) the
default column values were not. Defaults values for string literals are now properly quoted.

  • 6. MariaDB 10.2.7 information changes schema for default values.

In order to allow expressions as default values and distinguish them
from literals, Mariadb now quotes default values in information_schema.column table.
This changes brings a lot of incompatibilities between the (Oracle-)Mysql/MariaDB platforms.

Instead of creating a specific SchemaManager for MariaDB, the solution taken in this P/R is to map
the introduced changes in the current MySQLSchemaManager (method: getMariaDb1027ColumnDefault()).

From MariaDB 10.2.7, information schema changes includes:

  • NULL is now quoted as 'NULL' (see exceptions in https://jira.mariadb.org/browse/MDEV-14053. Unquoted null is technically possible)
  • String defaults are quoted (To save the string 'NULL', set the default as ''NULL'').
  • CURRENT_TIMESTAMP, CURRENT_DATE, CURRENT_TIME defaults are silently changed to 'current_timestamp()', 'currdate()', 'currtime()'.
    To prevent schema diff, they are mapped back to their original values.
  • (UPDATED) Partial support for default literal escaping have been done. Currently
    limited on schema introspection. #2850 will bring the support for backslashes in defaults later on
    but the code is ready.

See https://mariadb.com/kb/en/library/information-schema-columns-table/ for reference and
https://jira.mariadb.org/browse/MDEV-13132, https://jira.mariadb.org/browse/MDEV-13341 for history.

Will fix:

  • #2817 (invalid detection of column default values)
  • doctrine/doctrine2#6565 (schema update will alter all tables with columns_default='null')
  • 7. Support for MariaDB 10.2 reserved keywords.

  • 8. Added MariaDB 10.2 in travis (both pdo_mysql and mysqli)

Possible BC-breaks:

None found. Since the extraction of defaults escaping in #2850, there should be no impact on other platforms.

Portability concerns

  • Portability of CURRENT_TIME and CURRENT_DATE, mariadb 10.2 supports them, but no way to get back to mysql.

Issues that will be fixed by this P/R:

DBAL related:

  • #2817 (invalid detection of column default values)

ORM related:

Fix (or might fix) the following issues :

Other related open P/R

  • #2850 (Escaping of default values)

@belgattitude belgattitude changed the title from Fix for Mariadb 10.2.7 default column value and nulls (maraidb change). to Fix for Mariadb 10.2.7 default column value and nulls (mariadb change). Aug 26, 2017

@auviagroup

Tested solved the issue with mariadb 10.2.7... suggesting to change the comment in line 184 from "// for mariadb 10.2.7" to "// for mariadb 10.2+"

@belgattitude

This comment has been minimized.

Show comment
Hide comment
@belgattitude

belgattitude Aug 27, 2017

Contributor

Thanks @auviagroup , changed the comment to >= 10.2.7 instead. Don't know the policy of doctrine concerning code... maybe I'll remove.

Contributor

belgattitude commented Aug 27, 2017

Thanks @auviagroup , changed the comment to >= 10.2.7 instead. Don't know the policy of doctrine concerning code... maybe I'll remove.

Show outdated Hide outdated lib/Doctrine/DBAL/Schema/MySqlSchemaManager.php Outdated
Show outdated Hide outdated lib/Doctrine/DBAL/Schema/MySqlSchemaManager.php Outdated
Show outdated Hide outdated lib/Doctrine/DBAL/Schema/MySqlSchemaManager.php Outdated
Show outdated Hide outdated tests/Doctrine/Tests/DBAL/Functional/Schema/MySqlSchemaManagerTest.php Outdated
Show outdated Hide outdated tests/Doctrine/Tests/DBAL/Functional/Schema/MySqlSchemaManagerTest.php Outdated
Show outdated Hide outdated lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php Outdated
Show outdated Hide outdated lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php Outdated
Show outdated Hide outdated lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php Outdated
Show outdated Hide outdated lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php Outdated
Show outdated Hide outdated lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php Outdated
@belgattitude

This comment has been minimized.

Show comment
Hide comment
@belgattitude

belgattitude Aug 28, 2017

Contributor

Thanks a lot @morozov !!! I've updated the P/R with some of your remarks. Not yet 100% ready, but I'll see what's possible to improve tonight. See also my previous comment with the roadmap

Contributor

belgattitude commented Aug 28, 2017

Thanks a lot @morozov !!! I've updated the P/R with some of your remarks. Not yet 100% ready, but I'll see what's possible to improve tonight. See also my previous comment with the roadmap

@belgattitude

This comment has been minimized.

Show comment
Hide comment
@belgattitude

belgattitude Aug 28, 2017

Contributor

Hi @morozov , maybe you can point me to some direction. To be able to work with mysqli driver, I will have to changeMysqliConnection as well and make a detection more or less identical to the tests made in AbstractMysqlDriver::getServerVersion().

If you look in MysqliConnection:

    public function getServerVersion()
    {
        $majorVersion = floor($this->_conn->server_version / 10000);
        $minorVersion = floor(($this->_conn->server_version - $majorVersion * 10000) / 100);
        $patchVersion = floor($this->_conn->server_version - $majorVersion * 10000 - $minorVersion * 100);

        return $majorVersion . '.' . $minorVersion . '.' . $patchVersion;
    }

This won't work with things like 5.5.5-10.2.8-MariaDB-10.2.8+maria~xenial-log... It will return 5.5.5 instead of 10.2.8.

So I'm thinking to make something like:

    public function getServerVersion()
    {
        $serverInfo = $this->_conn->get_server_info();
        if (false !== stripos($serverInfo, 'mariadb')) { // optional, prevent one more method call if makes sense
            $version = MariaDbVersionStringParserOrBetterName::getVersion($serverInfo);
            if ($version !== null) {
                return $version;
            }
        }

        $majorVersion = floor($this->_conn->server_version / 10000);
        $minorVersion = floor(($this->_conn->server_version - $majorVersion * 10000) / 100);
        $patchVersion = floor($this->_conn->server_version - $majorVersion * 10000 - $minorVersion * 100);

        return $majorVersion . '.' . $minorVersion . '.' . $patchVersion;
    }

What would be a good name and namespace for MariaDbVersionStringParserOrBetterName, or can it be in platform (then it should be static) ?

Contributor

belgattitude commented Aug 28, 2017

Hi @morozov , maybe you can point me to some direction. To be able to work with mysqli driver, I will have to changeMysqliConnection as well and make a detection more or less identical to the tests made in AbstractMysqlDriver::getServerVersion().

If you look in MysqliConnection:

    public function getServerVersion()
    {
        $majorVersion = floor($this->_conn->server_version / 10000);
        $minorVersion = floor(($this->_conn->server_version - $majorVersion * 10000) / 100);
        $patchVersion = floor($this->_conn->server_version - $majorVersion * 10000 - $minorVersion * 100);

        return $majorVersion . '.' . $minorVersion . '.' . $patchVersion;
    }

This won't work with things like 5.5.5-10.2.8-MariaDB-10.2.8+maria~xenial-log... It will return 5.5.5 instead of 10.2.8.

So I'm thinking to make something like:

    public function getServerVersion()
    {
        $serverInfo = $this->_conn->get_server_info();
        if (false !== stripos($serverInfo, 'mariadb')) { // optional, prevent one more method call if makes sense
            $version = MariaDbVersionStringParserOrBetterName::getVersion($serverInfo);
            if ($version !== null) {
                return $version;
            }
        }

        $majorVersion = floor($this->_conn->server_version / 10000);
        $minorVersion = floor(($this->_conn->server_version - $majorVersion * 10000) / 100);
        $patchVersion = floor($this->_conn->server_version - $majorVersion * 10000 - $minorVersion * 100);

        return $majorVersion . '.' . $minorVersion . '.' . $patchVersion;
    }

What would be a good name and namespace for MariaDbVersionStringParserOrBetterName, or can it be in platform (then it should be static) ?

@belgattitude

This comment has been minimized.

Show comment
Hide comment
Contributor

belgattitude commented Aug 28, 2017

@morozov

This comment has been minimized.

Show comment
Hide comment
@morozov

morozov Aug 28, 2017

Member

What would be a good name and namespace for MariaDbVersionStringParserOrBetterName, or can it be in platform (then it should be static)?

According to the comment, the client just needs to strip the '5.5.5-' prefix, so I don't see the need in a special parser. Maybe we can just unify the logic of parsing MySQL and MariaDB versions so that we always parse the string representation, not the integer (because it doesn't work with all supported platforms).

Something like:

$serverInfo = $this->_conn->get_server_info();

if (false !== stripos($serverInfo, 'mariadb')) {
    $serverInfo = str_replace('5.5.5-', '', $serverInfo);
}

// parse $serverInfo
Member

morozov commented Aug 28, 2017

What would be a good name and namespace for MariaDbVersionStringParserOrBetterName, or can it be in platform (then it should be static)?

According to the comment, the client just needs to strip the '5.5.5-' prefix, so I don't see the need in a special parser. Maybe we can just unify the logic of parsing MySQL and MariaDB versions so that we always parse the string representation, not the integer (because it doesn't work with all supported platforms).

Something like:

$serverInfo = $this->_conn->get_server_info();

if (false !== stripos($serverInfo, 'mariadb')) {
    $serverInfo = str_replace('5.5.5-', '', $serverInfo);
}

// parse $serverInfo
@belgattitude

This comment has been minimized.

Show comment
Hide comment
@belgattitude

belgattitude Aug 28, 2017

Contributor

LGTM, I'll make a P/R... just trying to setup mariadb 10.2 on Travis and I'll commit

Contributor

belgattitude commented Aug 28, 2017

LGTM, I'll make a P/R... just trying to setup mariadb 10.2 on Travis and I'll commit

@belgattitude

This comment has been minimized.

Show comment
Hide comment
@belgattitude

belgattitude Aug 28, 2017

Contributor

Will fix this bug too: #2819.

Contributor

belgattitude commented Aug 28, 2017

Will fix this bug too: #2819.

@belgattitude

This comment has been minimized.

Show comment
Hide comment
@belgattitude
Contributor

belgattitude commented Aug 29, 2017

@belgattitude belgattitude changed the title from Fix for Mariadb 10.2.7 default column value and nulls (mariadb change). to Fix mariadb 10.2.7 default column values (nulls too) and mariadb detection Aug 29, 2017

@belgattitude

This comment has been minimized.

Show comment
Hide comment
@belgattitude

belgattitude Sep 1, 2017

Contributor

@Ocramius,

looks you're working crazily on doctrine ;) Feel free to contact me about this P/R, if you need change, infos... I'll try my best to respond quickly.

Keep up the great work and thanks a lot.

Contributor

belgattitude commented Sep 1, 2017

@Ocramius,

looks you're working crazily on doctrine ;) Feel free to contact me about this P/R, if you need change, infos... I'll try my best to respond quickly.

Keep up the great work and thanks a lot.

@belgattitude belgattitude reopened this Sep 2, 2017

@belgattitude

This comment has been minimized.

Show comment
Hide comment
@belgattitude

belgattitude Sep 2, 2017

Contributor

@Ocramius

I tried to reflect your advices (at least as far as I understood them ;). Note that I had to update the .travis.yml file in order to test mariadb-10.2.8. Check if you like it that way. Note also that since your feedbacks I've updated the mariadb reserved keywords from the latest doc. Don't be surprised

Regarding the 'current_timestamp()' issue, I'll try to find a solution in a couple of days. As this behaviour was not yet tested, I fear to introduce BC with mysql. I'll let you know the possible risks (I guess I will need to alias current_timestamp and current_timestamp() to be sure no-one gets a schema update with doctrine/orm. It can make the code a bit unsexy).

It took me a while to get into the project conventions and CI setup, hope I'll be less messy next time.

Thanks for your feedbacks and the time you spend on this project. Fantastic design :)

Contributor

belgattitude commented Sep 2, 2017

@Ocramius

I tried to reflect your advices (at least as far as I understood them ;). Note that I had to update the .travis.yml file in order to test mariadb-10.2.8. Check if you like it that way. Note also that since your feedbacks I've updated the mariadb reserved keywords from the latest doc. Don't be surprised

Regarding the 'current_timestamp()' issue, I'll try to find a solution in a couple of days. As this behaviour was not yet tested, I fear to introduce BC with mysql. I'll let you know the possible risks (I guess I will need to alias current_timestamp and current_timestamp() to be sure no-one gets a schema update with doctrine/orm. It can make the code a bit unsexy).

It took me a while to get into the project conventions and CI setup, hope I'll be less messy next time.

Thanks for your feedbacks and the time you spend on this project. Fantastic design :)

@belgattitude

This comment has been minimized.

Show comment
Hide comment
@belgattitude

belgattitude Sep 4, 2017

Contributor

@Ocramius,

As I'm leaving for a short 6 days break on wednesday 6th, I can possibly fix some things tomorrow... or when I come back.

Regarding current_timestamp() issue, the current patch does not break the current behaviour (no regression). The current situtation may be summarized as:

If you're using MariaDB 10.2 and you're setting current_timestamp as default value instead of current_timestamp(), a doctrine schema update will be triggerred because 10.2 always stores current_timestamp() in information_schema whatever value you sets. As a workaround, always write current_timestamp() as default value.

As this patch fixes a lot of others too (travis, proper mariadb detection, null and default quoted values in information_schema), you may want to merge it sooner. Feel free to do, I can also make a separate p/r for current_timestamp when I come back (around the 11th).

All the best

Contributor

belgattitude commented Sep 4, 2017

@Ocramius,

As I'm leaving for a short 6 days break on wednesday 6th, I can possibly fix some things tomorrow... or when I come back.

Regarding current_timestamp() issue, the current patch does not break the current behaviour (no regression). The current situtation may be summarized as:

If you're using MariaDB 10.2 and you're setting current_timestamp as default value instead of current_timestamp(), a doctrine schema update will be triggerred because 10.2 always stores current_timestamp() in information_schema whatever value you sets. As a workaround, always write current_timestamp() as default value.

As this patch fixes a lot of others too (travis, proper mariadb detection, null and default quoted values in information_schema), you may want to merge it sooner. Feel free to do, I can also make a separate p/r for current_timestamp when I come back (around the 11th).

All the best

@belgattitude

This comment has been minimized.

Show comment
Hide comment
@belgattitude

belgattitude Nov 21, 2017

Contributor

Special thanks for @morozov too... without him this P/R would have not happened !

Contributor

belgattitude commented Nov 21, 2017

Special thanks for @morozov too... without him this P/R would have not happened !

@tristanbes

This comment has been minimized.

Show comment
Hide comment
@tristanbes
Contributor

tristanbes commented Nov 21, 2017

yes, big thanks @morozov @belgattitude @lcobucci

@belgattitude belgattitude referenced this pull request Nov 21, 2017

Open

MariaDB 10.2 extended support (meta) #2923

0 of 4 tasks complete
@mpash

This comment has been minimized.

Show comment
Hide comment
@mpash

mpash Nov 21, 2017

@geeksareforlife What did you do to get your migrations to run, per this bug?

mpash commented Nov 21, 2017

@geeksareforlife What did you do to get your migrations to run, per this bug?

@geeksareforlife

This comment has been minimized.

Show comment
Hide comment
@geeksareforlife

geeksareforlife Nov 21, 2017

@mpash I never had an issue with the migrations running, just with the migration creation when the schema was compared to the database.

So at the moment I am just removing all the alter table statements that are generated, but that obviously makes an entry point for errors - I have had at least two occasions where I removed too many statements and had to go back!

geeksareforlife commented Nov 21, 2017

@mpash I never had an issue with the migrations running, just with the migration creation when the schema was compared to the database.

So at the moment I am just removing all the alter table statements that are generated, but that obviously makes an entry point for errors - I have had at least two occasions where I removed too many statements and had to go back!

@tristanbes

This comment has been minimized.

Show comment
Hide comment
@tristanbes

tristanbes Nov 29, 2017

Contributor

so, @belgattitude when do you think this patch can be released and tagged ? :)

Contributor

tristanbes commented Nov 29, 2017

so, @belgattitude when do you think this patch can be released and tagged ? :)

@neufeind

This comment has been minimized.

Show comment
Hide comment
@neufeind

neufeind Dec 5, 2017

TYPO3 is also looking forward to a new release so we can update the dependencies to have a release with this fix. Issue at TYPO3 referencing this: https://forge.typo3.org/issues/82023

neufeind commented Dec 5, 2017

TYPO3 is also looking forward to a new release so we can update the dependencies to have a release with this fix. Issue at TYPO3 referencing this: https://forge.typo3.org/issues/82023

@belgattitude

This comment has been minimized.

Show comment
Hide comment
@belgattitude

belgattitude Dec 5, 2017

Contributor

@tristanbes

when do you think this patch can be released and tagged ? :)

No idea. But in the meantime can you check everything is working for you ?

FYI, I had a report about some issues with dev-master on doctrine/doctrine2#6565 (look at the end of the thread). But finally it appears to be something unrelated.

Anyway, always good to test. Just try a schema creation/update with your project.

"require": {
        //...
        "doctrine/dbal": "2.7.x-dev as 2.6.10",
        //...
}

And let me know.

Contributor

belgattitude commented Dec 5, 2017

@tristanbes

when do you think this patch can be released and tagged ? :)

No idea. But in the meantime can you check everything is working for you ?

FYI, I had a report about some issues with dev-master on doctrine/doctrine2#6565 (look at the end of the thread). But finally it appears to be something unrelated.

Anyway, always good to test. Just try a schema creation/update with your project.

"require": {
        //...
        "doctrine/dbal": "2.7.x-dev as 2.6.10",
        //...
}

And let me know.

@DamienHarper

This comment has been minimized.

Show comment
Hide comment
@DamienHarper

DamienHarper Dec 7, 2017

@belgattitude @lcobucci : this release will be really appreciated by MariaDb users!

DamienHarper commented Dec 7, 2017

@belgattitude @lcobucci : this release will be really appreciated by MariaDb users!

@tristanbes

This comment has been minimized.

Show comment
Hide comment
@tristanbes

tristanbes Dec 7, 2017

Contributor

I can confirm @belgattitude that it fixes my problem.

Once the big migration has been generated and executed (a lot of ALTER TABLE xxx CHANGE yyy_id yyy_id INT DEFAULT NULL, CHANGE zzz_id zzz_id INT DEFAULT NULL) it does not keep trying to generate the same difffs

Contributor

tristanbes commented Dec 7, 2017

I can confirm @belgattitude that it fixes my problem.

Once the big migration has been generated and executed (a lot of ALTER TABLE xxx CHANGE yyy_id yyy_id INT DEFAULT NULL, CHANGE zzz_id zzz_id INT DEFAULT NULL) it does not keep trying to generate the same difffs

@DamienHarper

This comment has been minimized.

Show comment
Hide comment
@DamienHarper

DamienHarper Dec 7, 2017

@belgattitude @lcobucci @tristanbes I also confirm diffs are OK with these fixes

DamienHarper commented Dec 7, 2017

@belgattitude @lcobucci @tristanbes I also confirm diffs are OK with these fixes

@tristanbes

This comment has been minimized.

Show comment
Hide comment
@tristanbes

tristanbes Dec 8, 2017

Contributor

Well, @belgattitude it seems that it's not entirely fixed.

  1. changing a column name
  2. generating diffs -> it will output like 50 changes instead of one.

The only issue it seems to be fixed is that without touching the schema, the migrations are not longer generated when without this patch, it constantly generates diffs

Contributor

tristanbes commented Dec 8, 2017

Well, @belgattitude it seems that it's not entirely fixed.

  1. changing a column name
  2. generating diffs -> it will output like 50 changes instead of one.

The only issue it seems to be fixed is that without touching the schema, the migrations are not longer generated when without this patch, it constantly generates diffs

@belgattitude

This comment has been minimized.

Show comment
Hide comment
@belgattitude

belgattitude Dec 9, 2017

Contributor

hey @tristan, I cannot test right now cause I'm traveling for about a month without laptop. I'm not totally sure to understand your problem, if there is you'll have to wait till 27dec or try a pr.

Contributor

belgattitude commented Dec 9, 2017

hey @tristan, I cannot test right now cause I'm traveling for about a month without laptop. I'm not totally sure to understand your problem, if there is you'll have to wait till 27dec or try a pr.

@tristanbes

This comment has been minimized.

Show comment
Hide comment
@tristanbes

tristanbes Dec 9, 2017

Contributor

Let me rephrase it @belgattitude:
Before this patch:

  1. running doctrine:schema:upgrade --force ran the same queries always and always and always.
  2. changing 1 thing on the schema (let's say add a new $name field on an entity generates a migration diff with tons of changes ALTER TABLE xxx CHANGE yyy_id yyy_id INT DEFAULT NULL, CHANGE zzz_id zzz_id INT DEFAULT NULL

AFTER this patch

  1. running doctrine:schema:upgrade --force no longers runs the same queries again and again
  2. changing 1 thing on the schema (let's say add a new $name field on an entity generates a migration diff with tons of changes (in my case generates 67 diff statements instead of 1 in the form of: ALTER TABLE xxx CHANGE yyy_id yyy_id INT DEFAULT NULL, CHANGE zzz_id zzz_id INT DEFAULT NULL)

So 2/ is not fixed, and is really a pain in the *** when generating diff for your application
I hope it's more clear. Unfortunatly, doctrine at this low level is beyond my skills for a PR.

Contributor

tristanbes commented Dec 9, 2017

Let me rephrase it @belgattitude:
Before this patch:

  1. running doctrine:schema:upgrade --force ran the same queries always and always and always.
  2. changing 1 thing on the schema (let's say add a new $name field on an entity generates a migration diff with tons of changes ALTER TABLE xxx CHANGE yyy_id yyy_id INT DEFAULT NULL, CHANGE zzz_id zzz_id INT DEFAULT NULL

AFTER this patch

  1. running doctrine:schema:upgrade --force no longers runs the same queries again and again
  2. changing 1 thing on the schema (let's say add a new $name field on an entity generates a migration diff with tons of changes (in my case generates 67 diff statements instead of 1 in the form of: ALTER TABLE xxx CHANGE yyy_id yyy_id INT DEFAULT NULL, CHANGE zzz_id zzz_id INT DEFAULT NULL)

So 2/ is not fixed, and is really a pain in the *** when generating diff for your application
I hope it's more clear. Unfortunatly, doctrine at this low level is beyond my skills for a PR.

@belgattitude

This comment has been minimized.

Show comment
Hide comment
@belgattitude

belgattitude Dec 10, 2017

Contributor

@tristanbes, weird. I remember having done that without problem. but not sure.

/cc @Bukashk0zzz because he might help to test. I've done some debugging with him recently. doctrine/doctrine2#6565.

others might help too.it might be something else. testing dev-master includes more than my patch. could be nice to look deeper. at least see if it does not happen with mysql too.

Contributor

belgattitude commented Dec 10, 2017

@tristanbes, weird. I remember having done that without problem. but not sure.

/cc @Bukashk0zzz because he might help to test. I've done some debugging with him recently. doctrine/doctrine2#6565.

others might help too.it might be something else. testing dev-master includes more than my patch. could be nice to look deeper. at least see if it does not happen with mysql too.

@Bukashk0zzz

This comment has been minimized.

Show comment
Hide comment
@Bukashk0zzz

Bukashk0zzz Dec 11, 2017

@tristanbes @belgattitude

Made test for the case that @tristanbes discarded and all works ok no problem detected.

Code: Bukashk0zzz/dbal-test#3

Test:
https://travis-ci.org/Bukashk0zzz/dbal-test/builds/314640238

Bukashk0zzz commented Dec 11, 2017

@tristanbes @belgattitude

Made test for the case that @tristanbes discarded and all works ok no problem detected.

Code: Bukashk0zzz/dbal-test#3

Test:
https://travis-ci.org/Bukashk0zzz/dbal-test/builds/314640238

@tristanbes

This comment has been minimized.

Show comment
Hide comment
@tristanbes

tristanbes Dec 12, 2017

Contributor

@Bukashk0zzz : Mhhh, You have tested it against MariaDB 10.3. I'm having this issue for MariaDB 10.2. ("mariadb": "10.3" on your Travis configuration)

Contributor

tristanbes commented Dec 12, 2017

@Bukashk0zzz : Mhhh, You have tested it against MariaDB 10.3. I'm having this issue for MariaDB 10.2. ("mariadb": "10.3" on your Travis configuration)

@Bukashk0zzz

This comment has been minimized.

Show comment
Hide comment
@Bukashk0zzz

Bukashk0zzz commented Dec 13, 2017

@tristanbes No problem. Update to use MariaDB 10.2
Still all ok.

https://travis-ci.org/Bukashk0zzz/dbal-test/jobs/315753290

@tristanbes

This comment has been minimized.

Show comment
Hide comment
@tristanbes

tristanbes Dec 13, 2017

Contributor

I found what causes the problem. When specifying the server_version this patch has NO EFFECT. It generates the same migrations over and over again.

doctrine:
  dbal: 
    server_version: 10.2

As soon as I remove server_version parameter, it no longer generates the wrong diff.

Contributor

tristanbes commented Dec 13, 2017

I found what causes the problem. When specifying the server_version this patch has NO EFFECT. It generates the same migrations over and over again.

doctrine:
  dbal: 
    server_version: 10.2

As soon as I remove server_version parameter, it no longer generates the wrong diff.

@belgattitude

This comment has been minimized.

Show comment
Hide comment
@belgattitude

belgattitude Dec 14, 2017

Contributor

that makes sense. if you want to use server_version, you should set 10.2.7 instead of 10.2. the schema change appeared after 10.2.6. this will be confusing, but autodetection works.

Contributor

belgattitude commented Dec 14, 2017

that makes sense. if you want to use server_version, you should set 10.2.7 instead of 10.2. the schema change appeared after 10.2.6. this will be confusing, but autodetection works.

@tristanbes

This comment has been minimized.

Show comment
Hide comment
@tristanbes

tristanbes Jan 3, 2018

Contributor

Hello :-)
Sooooo, still no doctrine/dbal 2.7 so far ? I don't like to rely on dev-master for production :(

Contributor

tristanbes commented Jan 3, 2018

Hello :-)
Sooooo, still no doctrine/dbal 2.7 so far ? I don't like to rely on dev-master for production :(

@Ocramius

This comment has been minimized.

Show comment
Hide comment
@Ocramius

Ocramius Jan 3, 2018

Member

@tristanbes you guessed it right: no 2.7 yet ;-)

It will arrive, we're just not focused on it at the moment.

Member

Ocramius commented Jan 3, 2018

@tristanbes you guessed it right: no 2.7 yet ;-)

It will arrive, we're just not focused on it at the moment.

@jeffreymb

This comment has been minimized.

Show comment
Hide comment
@jeffreymb

jeffreymb Jan 3, 2018

I get the feeling that there would be multiple people that would be really happy to see this merged... Is there any way we can encourage this to receive some focus? 😄

jeffreymb commented Jan 3, 2018

I get the feeling that there would be multiple people that would be really happy to see this merged... Is there any way we can encourage this to receive some focus? 😄

@Ocramius

This comment has been minimized.

Show comment
Hide comment
@Ocramius

Ocramius Jan 3, 2018

Member

Not really, no.

Edit: to clarify (sorry, I'm just multitasking like crazy, didn't want to come off as rude), we're not working on pushing DBAL 2.7 out the door for now, but rather focused on stabelizing the ORM 3.0 development branch.

Member

Ocramius commented Jan 3, 2018

Not really, no.

Edit: to clarify (sorry, I'm just multitasking like crazy, didn't want to come off as rude), we're not working on pushing DBAL 2.7 out the door for now, but rather focused on stabelizing the ORM 3.0 development branch.

@neufeind

This comment has been minimized.

Show comment
Hide comment
@neufeind

neufeind Jan 5, 2018

Could we get this into the 2.6-branch maybe? Another project currently using DBAL 2.6.x would be happy to have at least initial MariaDB 10.2-support.

neufeind commented Jan 5, 2018

Could we get this into the 2.6-branch maybe? Another project currently using DBAL 2.6.x would be happy to have at least initial MariaDB 10.2-support.

@Ocramius

This comment has been minimized.

Show comment
Hide comment
@Ocramius

Ocramius Jan 5, 2018

Member

PSA: Additions are ONLY EVER for minor/major releases. Stop asking.

Member

Ocramius commented Jan 5, 2018

PSA: Additions are ONLY EVER for minor/major releases. Stop asking.

@doctrine doctrine locked as resolved and limited conversation to collaborators Jan 5, 2018

@Majkl578

This comment has been minimized.

Show comment
Hide comment
@Majkl578

Majkl578 Jan 6, 2018

Member

@belgattitude In future, please try to not mention people by @ in commit messages (GitHub and Bitbucket automatically link it to their users' accounts) - now I'm getting random e-mails about this commit even from Bitbucket because someone cherry-picked your PR. 😆 Thanks.

Member

Majkl578 commented on 4f876ef Jan 6, 2018

@belgattitude In future, please try to not mention people by @ in commit messages (GitHub and Bitbucket automatically link it to their users' accounts) - now I'm getting random e-mails about this commit even from Bitbucket because someone cherry-picked your PR. 😆 Thanks.

This comment has been minimized.

Show comment
Hide comment
@Ocramius

Ocramius Jan 6, 2018

Member

@Majkl578 tbh, mentioning is fine, but systems like bitbucket, as well as pushing to non-forks, can lead to a massive amount of noise.

Member

Ocramius replied Jan 6, 2018

@Majkl578 tbh, mentioning is fine, but systems like bitbucket, as well as pushing to non-forks, can lead to a massive amount of noise.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.