Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

SigalZ's avatar

How to create migration with int(10) field

OMG!!! I just hate Laravel migrations, I just hate it.

I do not want to use bigint as my id field and that causes so many problems, I lost the will to live.

I created a table called: origins:

Schema::create('origins', function (Blueprint $table) {
            $table->increments('id');
            $table->string('name');
            $table->string('slug');            
            $table->timestamps();
            $table->softDeletes();
        });

That created the id field as int(10)

Now I need to create countries table with a foreign key to origins:

This does not work, because it creates the origin_id field as int(11) and in the origins table the id is int(10)

Schema::create('countries', function (Blueprint $table) {
            $table->increments('id');
            $table->integer('origin_id');            
            $table->string('name');
            $table->timestamps();
            $table->softDeletes();
            $table->foreign('origin_id')->references('id')->on('origins')->constrained()
            ->onDelete('cascade');
        });

How do I set the integer to be 10 and not 11.

Can't use:

$table->foreignId('origin_id');

that creates it as bigint

can't use:

$table->foreignIdFor(User::class);

again, creates the field as bigint

this is so frustrating!

0 likes
18 replies
SigalZ's avatar

In case anyone else struggles, for some reason, making the integer unsigned change its size to 10:

$table->integer('origin_id', false, true);

I wish there was an option to specify the size. I also wish the documentation said anything about the option to add these parameters when creating an integer:

/**
     * Create a new integer (4-byte) column on the table.
     *
     * @param  string  $column
     * @param  bool  $autoIncrement
     * @param  bool  $unsigned
     * @return \Illuminate\Database\Schema\ColumnDefinition
     */
    public function integer($column, $autoIncrement = false, $unsigned = false)
OussamaMater's avatar

Well if you want to specify the length, simply pass it as the 2nd argument like so $table->integer('origin_id', 10);

And for foreign keys, if you're using the Laravel conventions (table_column => origin_id, which means look for id in origins table) you don't have to worry about manually doing it, Laravel takes cares of that, check the docs:

kokoshneta's avatar

@OussamaMater This:

Well if you want to specify the length, simply pass it as the 2nd argument like so $table->integer('origin_id', 10);

Is easy enough to say – but how do you figure it out? You might guess at it (since the string() method has length as the second argument), but the documentation doesn’t even mention a second argument, and the method signature (quoted in the question) calls the second and third arguments $аutoIncrement and $unsigned, which doesn’t exactly make it obvious that the second argument can be used for integer length.

Even looking through the maze of schema classes calling each other back and forth when running the integer() method, I can’t find where the second argument is actually used, and thus where it’s presumably tested for whether it should be used as an auto-increment value or an integer length.

This is probably my major pet peeve about Laravel – its documentation just is not up to scratch. You either get human-readable documentation that skips half the arguments and possibilities, or you’re forced to hunt through source code and guess how things fit together yourself.

2 likes
OussamaMater's avatar

@kokoshneta True, sometimes I have to read the code to be able to understand, sometimes a simple try to check if that works or not and sometimes a quick googling, but I truly appreciate the Laravel docs, I mean they're consistently updating it to be easier for all the new comers, I have worked with different frameworks that made appreciate our docs.

But trust me the Laravel team and our community are doing their best to make everything better and easier and we need to appreciate these efforts.

1 like
kokoshneta's avatar

@OussamaMater I know they do, and I do appreciate that the docs are very useful in many, many practical situations, particularly for newer users.

I just wish Laravel had a sort of in-between documentation as well – between the text-style docs that describe how to do things (showcasing classes and functions as means to an end) and the API that shows pure structure (leaving aside the question of what to do with that structure). Some documentation in the same style as the php.net docs, which are excellent: they show the signature of a function, describe what the function is for, and then give a description of each argument, what it may contain, and what the function will do with different values for the given argument.

That would be wonderful for Laravel!

1 like
OussamaMater's avatar

@kokoshneta Yes true, and actually considering to contribute in the docs this way like you stated, because it will be really helpful, and cut off all the conflicts, I totally agree in this point!

1 like
click's avatar

@OussamaMater did you test that this works? I doubt this works as the official documentation the second parameter is of the bool type so you cannot pass an integer to it see https://laravel.com/api/9.x/Illuminate/Database/Schema/Blueprint.html#method_integer

@sigalz If you want to define foreign keys the field types must be 100% equal. Both of the fields must be signed or unsigned, it is not possible to link an unsigned field to a signed field. So in all cases you must make sure you use the correct types.

OussamaMater's avatar

@click Yes I already mentioned that it should be the same size, he does know that as stated in his question, and yep it works, they just need to update the docs maybe? not really sure

kokoshneta's avatar

@click If you click through to the actual code, you can see that the arguments are not type-hinted at all – the bool definition only seems to exist in the API, not in the actual code.

SigalZ's avatar

@kokoshneta thank you! You expressed exactly what I feel. Although, after relaxing a bit, I have to say, Laravel is free, so we should say thank you for whatever we get :)

click's avatar

Is there a reason why you don't want unsigned big integers as your primary id's? It does help sometimes if you just "go with the flow" of Laravel.

OussamaMater's avatar

@click +1 for this, I mentioned it already, and true just have to follow the Laravel flow and save debugging and headache.

SigalZ's avatar

@click from my Google research bigint take more space and are slower. Why would I want bigint on a table that I know for sure will hold just a few records? Besides, I would like to have the freedom to choose what I need.

kokoshneta's avatar

@SigalZ It’s true that BIGINT takes up twice as much space as INT, but the difference is only 4 bytes per row. If you have a million rows, it will make your database 4 MB bigger – only an issue if you have very tight disk drive space constrictions, which isn’t the case for most servers.

The difference in performance is beyond minuscule – unless you have hundreds of millions of rows, there is no way you will ever be able to tell the difference.

So yes, there will be overhead in size and performance, but for 99.9% of use cases, that overhead is so insignificant as to be nonexistent.

You can of course be more deterministic and actively choose your types in detail, but as you’ve seen, that comes with having to jump through some hoops to make things like foreign keys work properly.

2 likes
SigalZ's avatar

@kokoshneta thank you so much for all the info. I really appreciate you for taking the time to write it all. You helped me understand more.

Snapey's avatar

you know you can add ->unsigned() to an integer column?

Please or to participate in this conversation.