Disable TINYINT(1) interpretation as BOOLEAN?

[AviBueno]

In MySQL, BOOL/BOOLEAN are defined as synonyms of TINYINT(1).

The opposite is not true, because TINYINT(1) ranges from -128 to +127 (signed) or 0 to 255 (unsigned).

There might be room for Propel to convert TINYINT(1) to a BOOLEAN - as a convenience method, in case a special configuration flag is explicitly switch on.
But performing this by default is just buggy.

For example, day_of_week tinyint(1) ranging from 0 to 6, should not be auto-converted to a boolean.

My question is:
Is there any way to bypass the code in MysqlSchemaParser which converts TINYINT(1) to a BOOLEAN?

[marcj]

No, there's no way as you see in the code. You should just change the schema.xml by hand when you generate it.

[AviBueno]

@marcj I'm not deeply familiar with the CLI tool, but I know that it's possible to somewhat extend/override the code, using --pluralizer-class for example.
That's why I asked if there's an alternative.

Currently we maintain a schema.sql file and auto-generate schema.xml based on it, and then generate the ORM classes. It seems we'll need to revise this workflow.

Thanks.

[marcj]

Well, of course you could extend the MysqlSchemaParser and use this custom class. But the would lead to code duplication.

[AviBueno]

I was actually thinking more in the direction of adding a "don't convert tinyint(1) to boolean" flag that could be switched on as a command line parameter, but changing our workflow will be a lot quicker.
Thank you for the replies.

[AviBueno]

FWIW, I'd like to update that going the other way around (i.e. generating the .sql file from schema.xml) turned out to be equally problematic because TIMESTAMP is converted to 'datetime', TINYINT(11) is converted to 'integer', etc.

• We have legacy code tables that are shared with other projects, so the SQL schema should adhere to mysqldump's format instead of Propel's sql:build's format.

Eventually, I decided to go with @marcj's suggestion and extend MysqlSchemaParser::getColumnFromRow() (although this is indeed not the optimal solution because code updates will need to be manually merged).

One note though:
MysqlSchemaParser::getColumnFromRow() has a line that's addressing $this->addVendorInfo.
Turns out that MysqlSchemaParser::addVendorInfo is declared as a private member, so I had to use Closure (better performance than reflection) in order to gain access to the private data member.

• It would have been preferred that classes that may be potentially extended, would declare non-public members as protected instead of private.