MariaDB 10.2.7 BC break #5614

@belgattitude commented on GitHub (Aug 26, 2017):

just published a P/R on https://github.com/doctrine/dbal/pull/2825 with the third approach... Feel free to comment.

@belgattitude commented on GitHub (Aug 26, 2017): just published a P/R on https://github.com/doctrine/dbal/pull/2825 with the third approach... Feel free to comment.

admin commented

@mdeboer commented on GitHub (Sep 6, 2017):

Same problem here, narrowed it down to it being a NULL problem of some sort as removing all nullable relations and fields solved it. That combined with me recently pulling the newest mariadb image for Docker explains it all.

There went another 3/4 hours of my day trying to find an error in my code even though the mapping files validated fine 😭 Using the mysql:5 image now which should fix things, fingers crossed 🤞 .

Hopefully a fix will be merged soon!

@mdeboer commented on GitHub (Sep 6, 2017): Same problem here, narrowed it down to it being a NULL problem of some sort as removing all nullable relations and fields solved it. That combined with me recently pulling the newest mariadb image for Docker explains it all. There went another 3/4 hours of my day trying to find an error in my code even though the mapping files validated fine 😭 Using the mysql:5 image now which should fix things, fingers crossed 🤞 . Hopefully a fix will be merged soon!

admin commented

@lcobucci commented on GitHub (Nov 19, 2017):

https://github.com/doctrine/dbal/pull/2825 has just been merged and it will be released on DBAL v2.7.0, please test if your issue is fixed when using "doctrine/dbal": "2.7.x-dev@dev" and let us know.

@lcobucci commented on GitHub (Nov 19, 2017): https://github.com/doctrine/dbal/pull/2825 has just been merged and it will be released on DBAL `v2.7.0`, please test if your issue is fixed when using `"doctrine/dbal": "2.7.x-dev@dev"` and let us know.

admin commented

2026-01-22 15:12:48 +01:00

@Bukashk0zzz commented on GitHub (Dec 3, 2017):

With "doctrine/dbal": "2.7.x-dev@dev" issue steel exist

@Bukashk0zzz commented on GitHub (Dec 3, 2017): With "doctrine/dbal": "2.7.x-dev@dev" issue steel exist

admin commented

@belgattitude commented on GitHub (Dec 3, 2017):

@Bukashk0zzz

Can you confirm, I don't have it anymore: My composer:

    "require": {
        "php": "^7.1",
        "doctrine/dbal": "2.7.x-dev as 2.6.4",
        "doctrine/common": "^2.7.0",
        "doctrine/orm": "^2.5.0",
        "gedmo/doctrine-extensions": "^2.4.28",
        "doctrine/data-fixtures": "^1.2.2",
        "symfony/console": "~2.6|~3.0|~4.0"
},

@belgattitude commented on GitHub (Dec 3, 2017): @Bukashk0zzz Can you confirm, I don't have it anymore: My composer: ``` "require": { "php": "^7.1", "doctrine/dbal": "2.7.x-dev as 2.6.4", "doctrine/common": "^2.7.0", "doctrine/orm": "^2.5.0", "gedmo/doctrine-extensions": "^2.4.28", "doctrine/data-fixtures": "^1.2.2", "symfony/console": "~2.6|~3.0|~4.0" }, ```

admin commented

@Bukashk0zzz commented on GitHub (Dec 3, 2017):

Tested with mariadb 10.2.11 and 10.3.1 official docker image.

in composer

        "symfony/orm-pack": "^1.0",
        "doctrine/dbal": "2.7.x-dev as 2.6.4",

Always get diff with null on every field.
On percona 5.7 and standard mysql 5.7 all works correct.

@Bukashk0zzz commented on GitHub (Dec 3, 2017): Tested with mariadb 10.2.11 and 10.3.1 official docker image. in composer ```json "symfony/orm-pack": "^1.0", "doctrine/dbal": "2.7.x-dev as 2.6.4", ``` Always get diff with null on every field. On percona 5.7 and standard mysql 5.7 all works correct.

admin commented

@belgattitude commented on GitHub (Dec 3, 2017):

@Bukashk0zzz ,

Weird, in my case, testing on 10.2.11-MariaDB-10.2.11+maria~xenial-log mariadb.org binary distribution works. As a simple reproducible test, I've just run a create update create/update based on openstore-schema-core project. (you can clone it if you like to test)

$ ./vendor/bin/doctrine orm:schema-tool:create 
ATTENTION: This operation should not be executed in a production environment.
Creating database schema...
Database schema created successfully!

Followed by an update:

$ ./vendor/bin/doctrine orm:schema-tool:update --dump-sql
Nothing to update - your database is already in sync with the current entity metadata.

So it's working fine.

I'm not aware of symfony/orm-pack but I guess it's not the problem. Could you confirm the latest 2.7 master have been fetched.... You can easily see by doing

$ ls -la vendor/doctrine/dbal/lib/Doctrine/DBAL/Platforms/Keywords

If there's a file named MariaDb102Keywords.php you should have the latest one. Otherwise it might be a composer problem.

Let me know. Thanks

@belgattitude commented on GitHub (Dec 3, 2017): @Bukashk0zzz , Weird, in my case, testing on `10.2.11-MariaDB-10.2.11+maria~xenial-log mariadb.org binary distribution` works. As a simple reproducible test, I've just run a create update create/update based on [openstore-schema-core](https://github.com/belgattitude/openstore-schema-core) project. (you can clone it if you like to test) ```sh $ ./vendor/bin/doctrine orm:schema-tool:create ATTENTION: This operation should not be executed in a production environment. Creating database schema... Database schema created successfully! ``` Followed by an update: ```sh $ ./vendor/bin/doctrine orm:schema-tool:update --dump-sql Nothing to update - your database is already in sync with the current entity metadata. ``` So it's working fine. I'm not aware of `symfony/orm-pack` but I guess it's not the problem. Could you confirm the latest 2.7 master have been fetched.... You can easily see by doing ```sh $ ls -la vendor/doctrine/dbal/lib/Doctrine/DBAL/Platforms/Keywords ``` If there's a file named `MariaDb102Keywords.php` you should have the latest one. Otherwise it might be a composer problem. Let me know. Thanks

admin commented

@belgattitude commented on GitHub (Dec 3, 2017):

@Bukashk0zzz,

Have you recreated the database before testing ? It's possible you've already applied the migration with 'NULLs' prior to the patch (so your default values have been broken). Can be an possibility too

@belgattitude commented on GitHub (Dec 3, 2017): @Bukashk0zzz, Have you recreated the database before testing ? It's possible you've already applied the migration with 'NULLs' prior to the patch (so your default values have been broken). Can be an possibility too

admin commented

@Bukashk0zzz commented on GitHub (Dec 4, 2017):

Made clear demo example https://github.com/Bukashk0zzz/dbal-test

With code in repo above I every time get diff. You can check it by yourself

@Bukashk0zzz commented on GitHub (Dec 4, 2017): Made clear demo example https://github.com/Bukashk0zzz/dbal-test With code in repo above I every time get diff. You can check it by yourself <img width="1234" alt="screen shot 2017-12-04 at 12 57 10" src="https://user-images.githubusercontent.com/1908342/33549454-3589ce30-d8f3-11e7-88a3-6bf0c7f64bc0.png">

admin commented

@Bukashk0zzz commented on GitHub (Dec 4, 2017):

I have one entity https://github.com/Bukashk0zzz/dbal-test/blob/master/src/Entity/Admin.php

And one init migration https://github.com/Bukashk0zzz/dbal-test/blob/master/src/Migrations/Version20171204100535.php

How I run project https://github.com/Bukashk0zzz/dbal-test/blob/master/up.sh

And after running I execute doctrine:migrations:diff or doctrine:schema:update

@Bukashk0zzz commented on GitHub (Dec 4, 2017): I have one entity https://github.com/Bukashk0zzz/dbal-test/blob/master/src/Entity/Admin.php And one init migration https://github.com/Bukashk0zzz/dbal-test/blob/master/src/Migrations/Version20171204100535.php How I run project https://github.com/Bukashk0zzz/dbal-test/blob/master/up.sh And after running I execute doctrine:migrations:diff or doctrine:schema:update

admin commented

@belgattitude commented on GitHub (Dec 4, 2017):

@Bukashk0zzz

Can you check by commenting server_version: '5.7' in config/packages/doctrine.yaml ?

Like this:

doctrine:
    dbal:
        # configure these for your database server
        driver: 'pdo_mysql'
        # server_version: '5.7'
        charset: utf8mb4

        # With Symfony 3.3, remove the `resolve:` prefix
        url: '%env(resolve:DATABASE_URL)%'

@belgattitude commented on GitHub (Dec 4, 2017): @Bukashk0zzz Can you check by commenting `server_version: '5.7'` in `config/packages/doctrine.yaml` ? Like this: ``` doctrine: dbal: # configure these for your database server driver: 'pdo_mysql' # server_version: '5.7' charset: utf8mb4 # With Symfony 3.3, remove the `resolve:` prefix url: '%env(resolve:DATABASE_URL)%' ```

admin commented

@belgattitude commented on GitHub (Dec 4, 2017):

With the commented server_version, everything looks good so far. Am I missing something ?

@belgattitude commented on GitHub (Dec 4, 2017): With the commented server_version, everything looks good so far. Am I missing something ? ![image](https://user-images.githubusercontent.com/259798/33550862-b4ea285e-d8ef-11e7-9e73-acae3671007c.png)

admin commented

@Bukashk0zzz commented on GitHub (Dec 4, 2017):

Still has problem with commented server_version: '5.7'

At your screenshot you just run migrations. Try run now for getting diff:

bin/console doctrine:migrations:diff
or
bin/console doctrine:schema:update --dump-sql

@Bukashk0zzz commented on GitHub (Dec 4, 2017): Still has problem with commented server_version: '5.7' At your screenshot you just run migrations. Try run now for getting diff: ```bash bin/console doctrine:migrations:diff or bin/console doctrine:schema:update --dump-sql ```

admin commented

@belgattitude commented on GitHub (Dec 4, 2017):

@Bukashk0zzz ...

Thanks, I can reproduce now... Could you help me to determine where the problem is ? I've just checked your entity, could you remove unsigned if you're using booleans ?

    /**
     * @var bool
     *
     * @ORM\Column(name="status", type="boolean", nullable=false, options={"default": true})
     */
    private $status = true;

And test with doctrine commands:

$ php bin/console doctrine:database:drop -n --force; php bin/console doctrine:database:create -n; php bin/console doctrine:schema:create -n
$ php bin/console doctrine:schema:update --dump-sql

It looks working... Either you change the status to integer or if you're using boolean remove "unsigned"="true".

Should be the same using migrations commands too.

Could you confirm you don't have migrations using mysql-5.7 ? So I can look deeper

@belgattitude commented on GitHub (Dec 4, 2017): @Bukashk0zzz ... Thanks, I can reproduce now... Could you help me to determine where the problem is ? I've just checked your [entity](https://github.com/Bukashk0zzz/dbal-test/blob/77ba5e40f1ccdc83ccdf67a6cd5c7e8e7ecc020a/src/Entity/Admin.php#L41), could you remove `unsigned` if you're using `booleans` ? ```php /** * @var bool * * @ORM\Column(name="status", type="boolean", nullable=false, options={"default": true}) */ private $status = true; ``` And test with doctrine commands: ```shell $ php bin/console doctrine:database:drop -n --force; php bin/console doctrine:database:create -n; php bin/console doctrine:schema:create -n $ php bin/console doctrine:schema:update --dump-sql ``` It looks working... Either you change the `status` to `integer` or if you're using `boolean` remove `"unsigned"="true"`. Should be the same using `migrations` commands too. Could you confirm you don't have migrations using mysql-5.7 ? So I can look deeper

admin commented

@belgattitude commented on GitHub (Dec 4, 2017):

Oups, just installed mysql-5.7... So with your entity, looks there's a diff generated as well:

$ rm -f src/Migrations/*.php
$ php bin/console doctrine:database:drop -n --force; php bin/console doctrine:database:create; php bin/console doctrine:schema:create -n
$ php bin/console doctrine:migrations:diff
# Generated new migration class to "/web/www/dbal-test/src/Migrations/Version20171204125419.php" from schema differences.

So I guess the same behaviour is for MySQL 5.7 too. So the way to fix is to fix your entity. Is there anything I missed ?

@belgattitude commented on GitHub (Dec 4, 2017): Oups, just installed mysql-5.7... So with your entity, looks there's a diff generated as well: ```shell $ rm -f src/Migrations/*.php $ php bin/console doctrine:database:drop -n --force; php bin/console doctrine:database:create; php bin/console doctrine:schema:create -n $ php bin/console doctrine:migrations:diff # Generated new migration class to "/web/www/dbal-test/src/Migrations/Version20171204125419.php" from schema differences. ``` So I guess the same behaviour is for MySQL 5.7 too. So the way to fix is to fix your entity. Is there anything I missed ?

admin commented

@Bukashk0zzz commented on GitHub (Dec 4, 2017):

Updated repo. Now boolean not unsigned.

Still get diff:

ALTER TABLE admins CHANGE login login VARCHAR(255) DEFAULT NULL, CHANGE password password VARCHAR(255) DEFAULT NULL;

Also on percona and official mysql all works correct.

@Bukashk0zzz commented on GitHub (Dec 4, 2017): Updated repo. Now boolean not unsigned. Still get diff: ALTER TABLE admins CHANGE login login VARCHAR(255) DEFAULT NULL, CHANGE password password VARCHAR(255) DEFAULT NULL; Also on percona and official mysql all works correct.

admin commented

2026-01-22 15:12:54 +01:00

@belgattitude commented on GitHub (Dec 4, 2017):

@Bukashk0zzz

Looks you've forgot to remove 'server_version' ? I've made a p/r https://github.com/Bukashk0zzz/dbal-test/pull/1, have a look:

Could you test by doing (exactly) this:

$ composer update
$ rm -f src/Migrations/*.php
$ php bin/console doctrine:database:drop -n --force; php bin/console doctrine:database:create; php bin/console doctrine:schema:create -n
$ php bin/console doctrine:migrations:diff

What I have is

# No changes detected in your mapping information.

@belgattitude commented on GitHub (Dec 4, 2017): @Bukashk0zzz Looks you've forgot to remove 'server_version' ? I've made a p/r https://github.com/Bukashk0zzz/dbal-test/pull/1, have a look: Could you test by doing (exactly) this: ```php $ composer update $ rm -f src/Migrations/*.php $ php bin/console doctrine:database:drop -n --force; php bin/console doctrine:database:create; php bin/console doctrine:schema:create -n $ php bin/console doctrine:migrations:diff ``` What I have is ``` # No changes detected in your mapping information. ```

admin commented

@belgattitude commented on GitHub (Dec 4, 2017):

Also note in your symfony.lock:

    "doctrine/dbal": {
        "version": "v2.6.3"
    },

Not sure exactly how it can affect.... but it could be the problem. To be sure check:

$ ls -la vendor/doctrine/dbal/lib/Doctrine/DBAL/Platforms/Keywords

If you're on the good doctrine version, you should have a MariaDb102Keywords.php file in it.

@belgattitude commented on GitHub (Dec 4, 2017): Also note in your `symfony.lock`: ```php "doctrine/dbal": { "version": "v2.6.3" }, ``` Not sure exactly how it can affect.... but it could be the problem. To be sure check: ``` $ ls -la vendor/doctrine/dbal/lib/Doctrine/DBAL/Platforms/Keywords ``` If you're on the good doctrine version, you should have a `MariaDb102Keywords.php` file in it.

admin commented

2026-01-22 15:12:54 +01:00

@Bukashk0zzz commented on GitHub (Dec 4, 2017):

Commenting 5.7 helped
Now all works correct. So there was two problems:

server_version: '5.7' in config
unsigned bool in mapping

Add travis check for this case https://travis-ci.org/Bukashk0zzz/dbal-test/builds/311377116

@Bukashk0zzz commented on GitHub (Dec 4, 2017): Commenting 5.7 helped Now all works correct. So there was two problems: - server_version: '5.7' in config - unsigned bool in mapping Add travis check for this case https://travis-ci.org/Bukashk0zzz/dbal-test/builds/311377116

admin commented

2026-01-22 15:12:56 +01:00

@mdeboer commented on GitHub (Dec 4, 2017):

Glad it's fixed (by the looks of it), when will this make it to master?

@mdeboer commented on GitHub (Dec 4, 2017): Glad it's fixed (by the looks of it), when will this make it to master?

admin commented

2026-01-22 15:12:56 +01:00

@belgattitude commented on GitHub (Dec 4, 2017):

@Bukashk0zzz, happy for you. server_version will bypass database detection, that explains. For the other one: unsigned bool in mapping, unsigned boolean (really tinyint(4)) does not play well with schema manager (same applies for Mysql 5.7, could you confirm ?).

@mdeboer Don't know when they are able to release, but in the meantime, please be welcome to test ;)

@belgattitude commented on GitHub (Dec 4, 2017): @Bukashk0zzz, happy for you. server_version will bypass database detection, that explains. For the other one: `unsigned bool in mapping`, unsigned boolean (really tinyint(4)) does not play well with schema manager (same applies for Mysql 5.7, could you confirm ?). @mdeboer Don't know when they are able to release, but in the meantime, please be welcome to test ;)

admin commented

@Bukashk0zzz commented on GitHub (Dec 5, 2017):

@belgattitude https://github.com/Bukashk0zzz/dbal-test/pull/2 as you can see mysql 5.7 have not any issue with unsigned bool. There are problems only with mariaDB

Check travis buid https://travis-ci.org/Bukashk0zzz/dbal-test/builds/311772602

You can create pull-request to this repo and test any cases you want.

@Bukashk0zzz commented on GitHub (Dec 5, 2017): @belgattitude https://github.com/Bukashk0zzz/dbal-test/pull/2 as you can see mysql 5.7 have not any issue with unsigned bool. There are problems only with mariaDB Check travis buid https://travis-ci.org/Bukashk0zzz/dbal-test/builds/311772602 You can create pull-request to this repo and test any cases you want.

admin commented

@belgattitude commented on GitHub (Dec 5, 2017):

@Bukashk0zzz

as you can see mysql 5.7 have not any issue with unsigned bool

Nope ! Your travis build show there's no migration, right ! But your entity does not have unsigned:true. So it's meaningless... (see 905ad233d5/src/Entity/Admin.php (L41))

To figure out, please test with 'unsigned:true' AND mysql5-7 (both conditions, don't forget to remove existing migrations rm -f src/Migrations/*.php if needed).

Anyway I just did the test on my laptop with mysql-5.7. And I can confirm, there's a migration happening with unsigned bool on mysql5.7 too.

Thanks

@belgattitude commented on GitHub (Dec 5, 2017): @Bukashk0zzz > as you can see mysql 5.7 have not any issue with unsigned bool Nope ! Your travis build show there's no migration, right ! But your entity does not have `unsigned:true`. So it's meaningless... (see https://github.com/Bukashk0zzz/dbal-test/blob/905ad233d52747e269ea76658e786a974ff971fc/src/Entity/Admin.php#L41) To figure out, please test with 'unsigned:true' AND mysql5-7 (both conditions, don't forget to remove existing migrations `rm -f src/Migrations/*.php` if needed). Anyway I just did the test on my laptop with mysql-5.7. And I can confirm, there's a migration happening with unsigned bool on mysql5.7 too. Thanks

admin commented

@Bukashk0zzz commented on GitHub (Dec 5, 2017):

@belgattitude You look at master not at PR and branch mysql

See PR files
https://github.com/Bukashk0zzz/dbal-test/pull/2/files

There are UNSIGNED in entity and in migration.

@Bukashk0zzz commented on GitHub (Dec 5, 2017): @belgattitude You look at master not at PR and branch mysql See PR files https://github.com/Bukashk0zzz/dbal-test/pull/2/files There are UNSIGNED in entity and in migration.

admin commented

b4dadcaa46/.travis.yml (L21)

@belgattitude commented on GitHub (Dec 5, 2017):

Ok, I still don't get it. Cannot reproduce but we are using 2 different ways to tests. I cannot help with doctrine:migrations... we need to start from dbal. Can you modify your travis scripts:

And only test with doctrine/dbal commands:

  - php bin/console doctrine:database:drop -n --force
  - php bin/console doctrine:database:create -n
  - php bin/console doctrine:schema:create -n
  - php bin/console doctrine:schema:update --dump-sql
  - php bin/console doctrine:schema:validate -n

This is what I have both unsigned:true and mysql 5.7

I'm not using doctrine:migrations, that why I've always removed rm -f src/Migrations/*.php just to be sure we work on the same schema specs. If the test above works for you, can you track it down to see where the migration process fails ?

@belgattitude commented on GitHub (Dec 5, 2017): Ok, I still don't get it. Cannot reproduce but we are using 2 different ways to tests. I cannot help with `doctrine:migrations`... we need to start from dbal. Can you modify your travis scripts: https://github.com/Bukashk0zzz/dbal-test/blob/b4dadcaa4672a314a40205368e798f523849b123/.travis.yml#L21 And only test with doctrine/dbal commands: ``` - php bin/console doctrine:database:drop -n --force - php bin/console doctrine:database:create -n - php bin/console doctrine:schema:create -n - php bin/console doctrine:schema:update --dump-sql - php bin/console doctrine:schema:validate -n ``` This is what I have both unsigned:true and mysql 5.7 ![image](https://user-images.githubusercontent.com/259798/33607484-931f2238-d9c1-11e7-8d03-90d249b1fb83.png) I'm not using doctrine:migrations, that why I've always removed `rm -f src/Migrations/*.php` just to be sure we work on the same schema specs. If the test above works for you, can you track it down to see where the migration process fails ?

admin commented

@belgattitude commented on GitHub (Dec 5, 2017):

For extended info, look what doctrine creates with unsigned: bools on mysql-5.7 or mariadb-10.2:

> php bin/console doctrine:schema:create --dump-sql

Here's the output (removed some columns for clarity):

CREATE TABLE admins (id INT UNSIGNED AUTO_INCREMENT NOT NULL,  status TINYINT(1) DEFAULT '1' NOT NULL, PRIMARY KEY(id))

It looks it didn't set the unsigned while creating...

But from schema introspection (schema:update) it always trigger a diff if using unsigned. DBAL seems to alias BOOL to TINYINT(1) and seems to remove unsigned property (mysql or mariadb). I don't think https://github.com/doctrine/dbal/pull/2825/ have changed that.

My question now is more about how 'doctrine:migrations' handles that. Can you eventually see if there's differences in generated migrations for both databases ? It can help me to track down the problem

Thanks

@belgattitude commented on GitHub (Dec 5, 2017): For extended info, look what doctrine creates with `unsigned: bools` on mysql-5.7 or mariadb-10.2: ``` > php bin/console doctrine:schema:create --dump-sql ``` Here's the output (removed some columns for clarity): ```sql CREATE TABLE admins (id INT UNSIGNED AUTO_INCREMENT NOT NULL, status TINYINT(1) DEFAULT '1' NOT NULL, PRIMARY KEY(id)) ``` It looks it didn't set the unsigned while creating... But from schema introspection (schema:update) it always trigger a diff if using unsigned. DBAL seems to alias BOOL to TINYINT(1) and seems to remove unsigned property (mysql or mariadb). I don't think https://github.com/doctrine/dbal/pull/2825/ have changed that. My question now is more about how 'doctrine:migrations' handles that. Can you eventually see if there's differences in generated migrations for both databases ? It can help me to track down the problem Thanks

admin commented

@Bukashk0zzz commented on GitHub (Dec 8, 2017):

@belgattitude You correct and on mysql and on mariadb with unsigned bool without my init migration always getting diff. Migrations generated by mysql and mariadb identical.

Answering on question how I get this migration:
I have already old project on ZF 1 and rewiring it to symfony 4 I just copy create table syntax from existing mysql db and set it to initial migration.

I agree with you that this not related to issue #2825

But what you think this are issue that dbal not correct handle unsigned bool ?
If yes I will create new issue. If no ok. Anyway I already fixed problem on my project.

travis test for mariadb https://travis-ci.org/Bukashk0zzz/dbal-test/builds/313452048

travis test for mysql https://travis-ci.org/Bukashk0zzz/dbal-test/builds/313450766

@Bukashk0zzz commented on GitHub (Dec 8, 2017): @belgattitude You correct and on mysql and on mariadb with unsigned bool without my init migration always getting diff. Migrations generated by mysql and mariadb identical. Answering on question how I get this migration: I have already old project on ZF 1 and rewiring it to symfony 4 I just copy create table syntax from existing mysql db and set it to initial migration. I agree with you that this not related to issue #2825 But what you think this are issue that dbal not correct handle unsigned bool ? If yes I will create new issue. If no ok. Anyway I already fixed problem on my project. travis test for mariadb https://travis-ci.org/Bukashk0zzz/dbal-test/builds/313452048 travis test for mysql https://travis-ci.org/Bukashk0zzz/dbal-test/builds/313450766

admin commented

2026-01-22 15:12:58 +01:00

@mdeboer commented on GitHub (Dec 8, 2017):

Why on earth would you use an unsigned bool anyway? Unless it's part of a bigger issue I don't see why this has priority to get fixed.

@mdeboer commented on GitHub (Dec 8, 2017): Why on earth would you use an unsigned bool anyway? Unless it's part of a bigger issue I don't see why this has priority to get fixed.

admin commented

@Bukashk0zzz commented on GitHub (Dec 9, 2017):

Why on earth would you use an unsigned bool anyway?

@mdeboer But why not? Near 6-7 years ago I always put unsigned for every integer that will be only with +
And that was good practice. Now I am using doctrine for a while and don't really look what created in db because all this things hided.

Anyway I agree that this not an issue for now. Thats why I asked and not created issue for that.
Also I think this issue can be closed @belgattitude tested everything.

@Bukashk0zzz commented on GitHub (Dec 9, 2017): > Why on earth would you use an unsigned bool anyway? @mdeboer But why not? Near 6-7 years ago I always put unsigned for every integer that will be only with + And that was good practice. Now I am using doctrine for a while and don't really look what created in db because all this things hided. Anyway I agree that this not an issue for now. Thats why I asked and not created issue for that. Also I think this issue can be closed @belgattitude tested everything.

admin commented

2026-01-22 15:12:58 +01:00

@lcobucci commented on GitHub (Dec 17, 2017):

@Bukashk0zzz awesome, closing then!

@lcobucci commented on GitHub (Dec 17, 2017): @Bukashk0zzz awesome, closing then!

admin commented

@musicjerm commented on GitHub (Apr 6, 2018):

This issue has resurfaced for me with a clean symfony/website-skeleton install. Running MariaDB 10.2.14 and doctrine/dbal v2.7.0. I compared against a fresh symfony-standard-edition connected to the same database. Verified doctrine/* versions are the same. Set up a simple entity to map with one field nullable=true and I get the issue on the symfony 4.0 install but not the 3.4. Anyone else able to confirm my insanity?

@musicjerm commented on GitHub (Apr 6, 2018): This issue has resurfaced for me with a clean symfony/website-skeleton install. Running MariaDB 10.2.14 and doctrine/dbal v2.7.0. I compared against a fresh symfony-standard-edition connected to the same database. Verified doctrine/* versions are the same. Set up a simple entity to map with one field nullable=true and I get the issue on the symfony 4.0 install but not the 3.4. Anyone else able to confirm my insanity?

admin commented

@remoteclient commented on GitHub (Jun 11, 2018):

I opened a new [issue]https://github.com/doctrine/doctrine2/issues/7258 for MariaDB 10.2.14 as this issue reappears there.

@remoteclient commented on GitHub (Jun 11, 2018): I opened a new [issue]https://github.com/doctrine/doctrine2/issues/7258 for MariaDB 10.2.14 as this issue reappears there.

admin commented

@belgattitude commented on GitHub (Jun 11, 2018):

@remoteclient I'll reply on #7258 7258

@belgattitude commented on GitHub (Jun 11, 2018): @remoteclient I'll reply on #7258 7258

admin commented