Unsupported laravel datatypes in doctrine/dbal

What do you mean by laravel data types? You probably need to stick with your MySQL data types.
And I know for a fact tiny int works with dbal. I use it for checkbox.

@jlrdw I meant the types listed in this table: https://laravel.com/docs/5.2/migrations#creating-columns And Laravel uses "tinyInteger" in column types instead of "TINYINT"

But you said you were going to use dbal.
Did you. Modifying Columns

Prerequisites

Before modifying a column, be sure to add the doctrine/dbal dependency to your composer.json file. The Doctrine DBAL library is used to determine the current state of the column and create the SQL queries needed to make the specified adjustments to the column.

@jlrdw Of course I've installed it. I said in the first line:

Installed doctrine/dbal as required

Also, look at the code: I've got the exception from "doctrine/dbal".

That library was supposed to give field-changing capability, but it is supposed to support everything that was already working. It is only mentioned that an "enum" columns cannot be altered this way. Nothing about unsupported conventional types.

Not a lot on this but I found this https://www.slideshare.net/mobile/MarkGarratt3/integrating-doctrine-with-laravel Can't view real good on the mobile.
You may want to search stackOverflow it's bound to have something.
Edit:
Was curious and dug and found https://github.com/laravel/framework/issues/6532 Read last comment. Sorry I missed the composer thing.

@jlrdw Regarding first link - thats about replacing Eloquent with Doctrine. Not my intention at all. Also, we are talking about an existing project that I want to add stuff to, not start from scratch.

Second link - it refers again to doctrine/dbal not supporting laravel column types – and is all about workarounds - finding another column type, that is supported by doctrine/dbal and is ok to use in Laravel. Then we should just use boolean/integer/double/string and be done with it.

There are 33 column types in laravel, and only 19 data types supported by doctrine/dbal. If doctrine/dbal is the way to go, then there should be an additional mapping file for extra column types, that are already in use by Laravel.

Well sometimes a workaround is the only way to fix something likewise if some additional functionality is needed perhaps you could put in a pull request. You do realize that migrations aren't necessary to use laravel right.

Doctrine doesn't have a mediumint type and this is a quick Google shows this is a well-hashed-over issue on both the Doctrine and Laravel sides. On the Laravel side, users register your same complaint, but unless Laravel writes this itself, it's dependent upon Doctrine to add to dbal.

You can see what Doctrine supports here: http://doctrine-orm.readthedocs.org/projects/doctrine-dbal/en/latest/reference/types.html#mapping-matrix

So, if you want to change with migration, you are limited to the types Doctrine supports (for the time being) which in your case would likely be integer.

You know it would not hurt anyone to use int instead of mediumint.

@preAristo If I understand your problem correctly, you seem to be dealing with a data type that is not supported by doctrine/dbal , then maybe this thread helps!

So again - documentation of Laravel is sub-par.

Laravel documentation is pretty vastly superior to any other framework.. and if it's not in the docs online, the code is well commented.

@willvincent good enough for me with about 15 years of experience, terrible for beginner (my wife), whom I cannot tell to follow the documentation, as even simple homestead installation had issues with undocumented steps. And now new feature to migrations, that has no mentioning in docs that it supports only half of column types.

But why the big over thinking of something so simple when you can just use int instead of mediumint.

@jlrdw it is more a rant of disappointment – new untested and partially documented functionality in good framework to begin with.

@preAristo I understand that. Frankly I was kind of disappointed myself in the documentation in version 5.2 vs 5.1. I think the docs for 5.1 had a lot more little examples for a new person to catch on to. And that middleware web thing in 5.2 had to be fixed that confused a lot of people. Of course I'm still on 5.1 haven't really used 5.2 for real yet just set it up for testing.
Even when I set up 5.2 I'd actually refer back to my 5.1 install to get some stuff working. There is nothing like good documentation with good examples.

Here are some solutions, some fast but with consequences, and others that you would need more time, but would be more robust. There is no one solution better than the other, each one is just different.

1. As a fast solution, and only if you are not going to change the connection driver to something but MySQL:

DB::connection('connection_name')->statement(
  "ALTER TABLE `table_name` CHANGE `i_process_pid` `starting_price` MEDIUMINT(10)  UNSIGNED  NULL  DEFAULT NULL;"
);

1. For table creation, it works, but not for change, so you can drop your table and create it again.

2. Map the midiumint type as a integer, which would make an impact into the database size and performance: https://symfony.com/doc/current/doctrine/dbal.html#registering-custom-mapping-types-in-the-schematool I did this kind of mapping for enum, in one open source project I did, maybe you could adapt some code from it: https://github.com/Triun/laravel-model-base/blob/v5.6.1/src/Utils/SchemaUtil.php#L104 https://github.com/Triun/laravel-model-base/blob/v5.6.1/config/model-base.php#L495

1. Create a custom type, which would be the more complex option, but also the perfect one (if you want to spend the time).