tinyint missing from getTypesMap()

[intrepidws]

The best way to explain this is probably to reference this issue:

laravel/framework#8840

The Laravel framework uses DBAL for alterations to existing fields. Basically, it looks like the tinyint definition is missing, at least from some aspects of DBAL. It's not possible to change an existing field to a tinyint - when you try, it returns the following error:

DBALException in DBALException.php line 228:
Unknown column type "tinyinteger" requested. Any Doctrine type that you use has to be registered with \Doctrine\DBAL\Types\Type::addType(). You can get a list of all the known types with \Doctrine\DBAL\Types\Type::getTypesMap(). If this error occurs during database introspection then you might have forgot to register all database types for a Doctrine Type. Use AbstractPlatform#registerDoctrineTypeMapping() or have your custom types implement Type#getMappedDatabaseTypes(). If the type name is empty you might have a problem with the cache or forgot some mapping information.

I was just wondering if maybe this was done for a reason? Or just an oversight?

If not - I'd love to try and contribute and fix this - are there any contributing guidelines or instructions?

[deeky666]

"Tiny integer" is not supported by many database vendors. DBAL's type system is an abstraction layer for SQL types including type conversion from PHP to database value and back. I am assuming that your issue refers to MySQL, where we do not have a distinct native SQL type to use for BooleanType mapping. Therefore MySQL's TINYINT is used for that purpose as is fits best from all available native types and in DBAL we do not have an abstraction for tiny integers as such (as mentioned above).
What you can do is implement your own tiny integer custom type and tell DBAL to use column comments (for distinction from BooleanType in MySQL). That should work. See the documentation.
To tell DBAL to use column comments for the custom type, simply override the requiresSQLCommentHint() method to return true.

Hope this helps.

[jlsjonas]

"Tiny integer" is not supported by many database vendors.

A quick google search seems to indicate only postgres doesn't seem to include support for it; where a bigger smallint could be used as a viable alternative

It doesn't make sense in my eyes not to include this natively as most widely-used databases support it (MySQL, MariaDB, SQL Server, SQLite, Oracle)

Notable, Drizzle doesn't support smallint; yet smallint is fully supported, so presumably it shouldn't be an issue to support tinyint for everything but the above (and use smallint/int instead for them)
ping @deeky666

[Ocramius]

Sorry, this won't be changed: you are free to use custom DBAL types in userland, but it won't be added to DBAL itself, as what @deeky666 said still stands.

[jlsjonas]

as what @deeky666 said still stands.

I'm sorry, but what part of it? I stated in my last comment how all but 2 of the supported databases support tinyint, and one of them doesn't support smallint either; yet smallint is supported in doctrine. This is just an inconsistency and one that doesn't make any sense in my eyes (and several others looking at the past activity in this thread, and popularity on google, SO, ... .

[Ocramius]

As long as it's not supported by all of the platforms that we run with, it's gonna stay out of DBAL.

Implementing a custom type in userland is trivial: do that instead. Here it won't be added for now.

[jlsjonas]

As long as it's not supported by all of the platforms that we run with, it's gonna stay out of DBAL.

Then please explain how smallint is supported? (as Drizzle doesn't seem to support that either)
Just implement it the same way as was done for smallint? tinyint for platforms that support it, smallint postgres and (presumably?) int for Drizzle

[Ocramius]

It's mapped in

dbal/lib/Doctrine/DBAL/Types/Type.php

Line 65 in 0731608

self::SMALLINT => SmallIntType::class,

That's extremely old and indeed a mistake that shouldn't be repeated. You have to look at this from a maintenance PoV: the more custom platform-specific features we add to DBAL, the more maintenance spawns (and that happens every time we add a bit of support for anything that isn't fully standard).

I'm closing and locking here: ain't gonna happen, and that's final.