Jira issue originally created by user stefano.kowalke:
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 :-)
Comment created by @deeky666:
[~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. :)
Comment created by stefano.kowalke:
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.
Issue was closed with resolution "Invalid"
Comment created by jonny827:
@Steve Muller - I believe Doctrine2 developers made a huge design flaw in doing this for the following reasons:
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.
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.
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.
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.