Uploaded image for project: 'Doctrine DBAL'
  1. Doctrine DBAL
  2. DBAL-781

Doctrine maps tinyint with length > 1 to boolan

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Minor
    • Resolution: Invalid
    • Affects Version/s: 2.4.2
    • Fix Version/s: None
    • Component/s: None
    • Security Level: All
    • Environment:
      OSX 10.8, PHP 5.4, MySQL 5.6

      Description

      Why Doctrine maps any tinyint, regardless its length to boolean type. According to the MySQL Documentation only tinyint(1) is equivalent to boolean. I searched the web and found only out that this is the way how Doctrine it does but not why, so I have to assume its a bug.

      Hope someone who knows Doctrine better could enlighten me

        Issue Links

          Activity

          Hide
          deeky666 Steve Müller added a comment - - edited

          Stefano Kowalke The length parameter for MySQL's integer does not have any effect unless you use it in conjunction with the ZEROFILL attribute. It does not have any meaning concerning min or max value and the storage requirements for that specific type but only specifies the display length for zerofill characters.

          M indicates the maximum display width for integer types. For floating-point and fixed-point types, M is the total number of digits that can be stored. For string types, M is the maximum length. The maximum allowable value of M depends on the data type.

          As MySQL does not have a native boolean type, Doctrine uses it to map it's own boolean type as it is the one that comes closest to a "boolean" type column. This is not a bug in Doctrine but an expected behaviour.
          Hope I could clarify this.

          Show
          deeky666 Steve Müller added a comment - - edited Stefano Kowalke The length parameter for MySQL's integer does not have any effect unless you use it in conjunction with the ZEROFILL attribute. It does not have any meaning concerning min or max value and the storage requirements for that specific type but only specifies the display length for zerofill characters. M indicates the maximum display width for integer types. For floating-point and fixed-point types, M is the total number of digits that can be stored. For string types, M is the maximum length. The maximum allowable value of M depends on the data type. As MySQL does not have a native boolean type, Doctrine uses it to map it's own boolean type as it is the one that comes closest to a "boolean" type column. This is not a bug in Doctrine but an expected behaviour. Hope I could clarify this.
          Hide
          stefano.kowalke Stefano Kowalke added a comment -

          Hey Steve, thanks for your detailed informations. This helped me to understand the behavior and gave me a direction how to get more background informations.

          Show
          stefano.kowalke Stefano Kowalke added a comment - Hey Steve, thanks for your detailed informations. This helped me to understand the behavior and gave me a direction how to get more background informations.
          Hide
          jonny827 Jonathan added a comment -

          @Steve Muller - I believe Doctrine2 developers made a huge design flaw in doing this for the following reasons:

          1. MySQL doesnt have boolean type but it supports BIT(1) which in my more novice opinion would be more effective if you wanted to use something to map. OR just not made a boolean type. Ideally, a programmer would go I am using the MySQL database engine, no boolean, let me use a TINY INT. So instead of making the programmer think you dumbed down a field that can store 255unsigned valyes into one that stores TRUE OR FALSE.

          2. Now I need to use 2 bytes of data to store the integer 2-255unsigned in smallint. So think about all of the fields that could use TINYINT to store configurations or settings where there is more than a true false. Account types, account status, day of week, day of month, current AGE, date at death, age required to do XYZ, You do not offer enum and you made a strong tiny integer into a weak bipolar newborn.

          3. By requiring two bites of data to these fields you will be double the data storage in probably 1 out of 5 of my columns. If you had a million records with this issue that is an extra 1MB of unneeded database size. This may slow performance of select and other MySQL operation fractionally.

          4. In summary, you spoon fed developers a weak FAT bipolar newborn. Give us back out functionality, allow us to trim down and NORMALIZE properly, stop cross-mapping data types. You take away all enum options. This is ONE major major major major benefit of Propel is that they at least have TINYINT. Also: built in behaviors versus complaining that its too hard to test and maintain behaviors. I respect Doctrine and chose it for its stability and strength. Everyone makes mistakes but please fix this one. Sorry in advance for being rude but I preferred being honest versus being a suck-up.

          Love your application, thank you very much for being SPL friendly(data mapper) stable 2.x, part of symphony install by default/massive tutorial/knowledge base online, more contributors, active contributors, ROADMAP(they refuse to use one in PROPEL), easier to unit test. I spent weeks reading every word about both. Thank you for listening.

          Show
          jonny827 Jonathan added a comment - @Steve Muller - I believe Doctrine2 developers made a huge design flaw in doing this for the following reasons: 1. MySQL doesnt have boolean type but it supports BIT(1) which in my more novice opinion would be more effective if you wanted to use something to map. OR just not made a boolean type. Ideally, a programmer would go I am using the MySQL database engine, no boolean, let me use a TINY INT. So instead of making the programmer think you dumbed down a field that can store 255unsigned valyes into one that stores TRUE OR FALSE. 2. Now I need to use 2 bytes of data to store the integer 2-255unsigned in smallint. So think about all of the fields that could use TINYINT to store configurations or settings where there is more than a true false. Account types, account status, day of week, day of month, current AGE, date at death, age required to do XYZ, You do not offer enum and you made a strong tiny integer into a weak bipolar newborn. 3. By requiring two bites of data to these fields you will be double the data storage in probably 1 out of 5 of my columns. If you had a million records with this issue that is an extra 1MB of unneeded database size. This may slow performance of select and other MySQL operation fractionally. 4. In summary, you spoon fed developers a weak FAT bipolar newborn. Give us back out functionality, allow us to trim down and NORMALIZE properly, stop cross-mapping data types. You take away all enum options. This is ONE major major major major benefit of Propel is that they at least have TINYINT. Also: built in behaviors versus complaining that its too hard to test and maintain behaviors. I respect Doctrine and chose it for its stability and strength. Everyone makes mistakes but please fix this one. Sorry in advance for being rude but I preferred being honest versus being a suck-up. Love your application, thank you very much for being SPL friendly(data mapper) stable 2.x, part of symphony install by default/massive tutorial/knowledge base online, more contributors, active contributors, ROADMAP(they refuse to use one in PROPEL), easier to unit test. I spent weeks reading every word about both. Thank you for listening.

            People

            • Assignee:
              beberlei Benjamin Eberlei
              Reporter:
              stefano.kowalke Stefano Kowalke
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: