> mobileapp Strategy - From Idea to Mobile App RealityVinova Our team will brainstorm with you on where to begin, where to go, and how to get you there. Whether you have a spark of an idea or an existing app – we can help. Getting your mobile strategy right is what our unique services are all about. We’ll wrestle with business challenges, discover new opportunities that will help you define and refine your product ideas into mobile app reality.

Be Careful: Laravel 5.8 Added bigIncrements As Defaults – Laravel Daily

Be Careful: Laravel 5.8 Added bigIncrements As Defaults – Laravel Daily

There is one change in Laravel 5.8 that is not mentioned in the official Upgrade Guide but caused me problems – I couldn’t create a foreign key migration, and spent half-hour until found out the reasons. So I want to share, maybe you will encounter the same thing.

My Situation Example and Error

While working on one project, I’ve created a simple table transaction_types:

And added just one new string() field:

And then tried to create a migration for transactions table with a foreign key, with same syntax I used to do all the time:

Migration file content:

And here’s what happened when running php artisan migrate:

As usual, the error “cannot add foreign key constraint” doesn’t give much details so I was just guessing, what could go wrong:

Look closer at what Laravel is generating when doing php artisan make:migration command:

bigIncrements. BIG increments. And then, of course, if you’re doing a foreign key from just “unsigned integer” type (as I always did my whole life), it fails. Type mismatch. Obviously.

How to Fix

Well, it’s easy. There are two ways to make it work:

The choice is yours.

Why Am I so Angry About It

Simple – this change wasn’t mentioned anywhere in 5.8 changes.

So, it makes me think that probably it’s only me with this problem, and everyone else will actually notice that migrations are being generated with bigIncrements().

After some googling, I’ve found one Reddit thread and one Stackoverflow post about it. That’s it.

Oh, and, of course, it was mentioned and discussed in the official Github repository of Laravel, back in November 2018:

Don’t get me wrong, I’m not against that change to bigIncrements(). I’m just angry about how it was (NOT) communicated. Probably only a bunch of people participating in internal Github communications actually knew about this change.

P.S. Oh, by the way, default users table migration also comes with bigIncrements():

So whenever you create new fields with foreign key to users, don’t forget to use bigInteger().

Like our articles?
Check out our Laravel online courses!

This content was originally published here.

Malcare WordPress Security

singapore mobile application developer,mobile developer singapore,web designer singapore,mobile app developer singapore,app developer singapore,web design services singapore,ios developer singapore,singapore web design,web development singapore,ruby on rails developer singapore,mobile application developer singapore,design firms in singapore,singapore website design,website developer singapore,web design singapore,mobile apps development singapore,web design company singapore,mobile app development singapore,graphic designer in singapore,app development singapore,android developer singapore,website design singapore,design agency singapore,developers in singapore,singapore mobile app developer,mobile apps singapore,developer in singapore,mobile application development singapore,singapore web development,ios app development singapore,web application singapore,website designer singapore,singapore app developer,web development company singapore,website development singapore,singapore web design services,mobile game developer singapore