All right, welcome back. We have a decent PR that we need to look over and merge. So if we check this out, upgrade to Laravel 5.6. At the moment, Council is running on 5.5. But yeah, by the time we get to an actual release, we want to get this on the latest version of Laravel for sure. So luckily, it looks like Darka Online has gone through the process of doing this for us. Otherwise, you could go to laravel.com/docs/upgrade. And actually, in this particular instance, it's a fairly fast process, nothing too crazy there. But anyways, it's still good for things like this, where you're changing framework code, you're updating dependencies, lots of little tweaks there, you have to be careful. And this is where a full test suite becomes an extreme benefit. Now I see here there's only 10 files changed, not too bad. So let's quickly scan it, then we'll try it out, we'll address any quirks,

is where a full test suite becomes an extreme benefit. Now I see here there's only 10 files changed, not too bad. So let's quickly scan it, then we'll try it out, we'll address any quirks, and then we'll be good to go. So one of the new features in Laravel 5.6 is upgraded logging capabilities. So it looks like we need an environment variable for that. Now, yeah, this is one thing. So if we switch back, I did notice this. As part of the upgrade to 5.6, he fixed a bug or he or she fixed a bug. When a best reply is deleted, its ID is not unset from the thread. So that's a database thing. Basically, think about it, for a thread, if a User leaves a reply that is marked as the best one, then as you know, we update a column. And in fact, I'll show you right here on the threads table. So yeah, we have this column. If you leave a reply, the creator marks that one as the best reply, then it gets recorded here. But

And in fact, I'll show you right here on the threads table. So yeah, we have this column. If you leave a reply, the creator marks that one as the best reply, then it gets recorded here. But now imagine that the user deletes the reply. Well, as part of that deletion, or using a model hook, we need to make sure that we update the original thread column to set that value to null so that we don't break anything. So we have that. But it looks like as part of his upgrade to 5.6, that broke and they had to change some things. So we'll need to address that for sure. Anyways, in this case, it looks like they're fixing it by not depending upon the foreign key constraint. But instead, they're updating that column with php. So here's this method they added to allow for it to unset the best reply. I don't like this terminology. I'll say that unset is a very programmer-y term. And whenever you feel like you're using too many programming

added to allow for it to unset the best reply. I don't like this terminology. I'll say that unset is a very programmer-y term. And whenever you feel like you're using too many programming terms, I feel like you're missing something. Instead, what would you write in this particular case, even if it's as simple as remove best reply, right? It's a bit more of a human way to speak of it. So anyways, I'm going to keep this for now. But I would really like to fix whatever issue there was with the upgrade to 5.6 so that I can then delete this method entirely. All right, what else? So we have some version updates, standard stuff there. In config/app.php, because logging is more of a first-class citizen now, that, as I understand, it gets its own file and it does. So in situations like this, they're just copy and pasting it from the Laravel 5.6 repo. And if you go through the upgrade guide, often that's what they will tell

it gets its own file and it does. So in situations like this, they're just copy and pasting it from the Laravel 5.6 repo. And if you go through the upgrade guide, often that's what they will tell you to do. Copy this file here to your project. So here we have the logging, and then it looks like hashing is now configurable, so that you can choose a default of a bcrypt driver, or you can use argon if you want to. All right, standard stuff. This one I read about as well. So now if you create a model or you create a record, and then you return that from the route, that will now be a 201 rather than a 200 status code. Now, for those uninformed, a 200 status code is like your server's way of saying, yep, all good, we're fine, you know, everything's okay here. A 201 is a slight tweak on that. It's saying, okay, I have created the resource. I've created the thing in question. So it's a slight tweak, but it does make more sense in that case.

Travis end, this seems to break, which is odd. Okay, so we update those two cases. All right, not too bad. I've seen version upgrades that are significantly more in depth. So this is pretty great. Let's go ahead and merge it in, try it out, run the test suite, address anything, and then we'll call it a day. So at the bottom here, I'm going to use it from the command line. We'll check out a new branch and then pull in these changes. All right, let's now do a composer install and finally run my phpunit suite. All right, everything seems to be looking good. Yeah, and we're good to go. So once again, think of the assurance that this provides us. Because we have this full test suite, we know that virtually everything works. Whereas if we didn't have this, you'd just sort of have to click around the site to see if anything broke, and you're never going to go through every possible path through your application.

didn't have this, you'd just sort of have to click around the site to see if anything broke, and you're never going to go through every possible path through your application. So the likelihood that you will push to production some kind of bug is way, way higher than it would be if you had a full test suite. All right, so now let's come back and give this a refresh. Everything seems to be working exactly the way it did before. And if I do a php artisan -v, we're now on Laravel 5.6. But now, yeah, real quick to finish up, I do want to address this one issue here about fixing the bug. So let's see where that was. Okay, so this is the test. It was working on Laravel 5.5, but with the upgrade to 5.6, it's no longer working. So I'm curious about this. Let's go to that method. If a bestReply is deleted, then the thread is properly updated to reflect that.

it's no longer working. So I'm curious about this. Let's go to that method. If a bestReply is deleted, then the thread is properly updated to reflect that. Yeah, so this is exactly what we were seeing before. If a thread has already marked that that reply is the best one, but then that reply is deleted, well, we have to update the thread column to remove that bestReply row. Now, the way we do that in our migration is through a foreign key constraint. This says on the threads table, we have this column called best_reply_id, and that actually points to the id column on the replies table. However, if one of those replies is deleted, well, on the case that it's deleted, we're going to update the best_reply_id column, and we're going to set that value to null. So yeah, this is confusing because it works on 5.5, but it looks like it doesn't in 5.6. Let's confirm it. If we go to the Reply model,

column, and we're going to set that value to null. So yeah, this is confusing because it works on 5.5, but it looks like it doesn't in 5.6. Let's confirm it. If we go to the Reply model, here's this new bit of code that the contributor added to make it work. Let's just remove it entirely and then rerun the test. And it fails. Failed asserting that 1 is null. So we're expecting that foreign key to take effect, but it's not, and I don't know why. This is one of the realities of just being a developer in general, not just running an open source project, but being a developer in general. You will run across things that you do not know, and this is one of them for me. Now, we can go through a couple steps to try to solve it, but my guess is that we're going to have to accept the PR as it is, and then maybe later, if we figure it out, we can

Now, we can go through a couple steps to try to solve it, but my guess is that we're going to have to accept the PR as it is, and then maybe later, if we figure it out, we can create a new commit that brings it back to the way it was before. But some things that I might do. Well, it sounds like, to me, there's some issue on the database end. So what I might do is isolate it. So you'll see in our phpunit.xml file, we're using an SQLite database in memory. I wonder if it still happens if we're using MySQL. So let's see if we can isolate where the problem is. So let's change that to MySQL, and then the database we'll call console_testing. It's just temporary. I'm going to delete it in just a few minutes. I do need to create that now. So in SQL Pro, I will add a database called console_testing. Now we do need to run the migrations. So here's a quick way we can do that. In my .env file, let's just update this,

Pro, I will add a database called console_testing. Now we do need to run the migrations. So here's a quick way we can do that. In my .env file, let's just update this, and then run php artisan migrate, and then just bring it back to what we had before. Okay, so now in SQL Pro, if we give this a refresh, we have that table there, which means all of our phpunit tests will use this table. Okay, so let's isolate this. We're going to run it again, and whoops, we have an error related... oh yeah, so on TestCase, right here, and you know what? I have a suspicion this is related to the issue. But yeah, by default, when using SQLite, foreign key constraints are not enabled. They are disabled by default. So this is the SQLite command you would run to enable them that allows for this very thing. So I'm guessing this is related to the problem, but anyways, it's SQLite specific, not MySQL, so I will comment that out,

command you would run to enable them that allows for this very thing. So I'm guessing this is related to the problem, but anyways, it's SQLite specific, not MySQL, so I will comment that out, and then give it another run, and what do you know? We do get green. So what we've found is that in Laravel 5.5, this bit of code, something related to foreign key constraints, works on MySQL and SQLite. On Laravel 5.6, and I don't think this is a Laravel issue, I'm not sure, but my instinct is it's usually not. Usually it's something unrelated. But anyways, in Laravel 5.6, it works in MySQL. It does not work within SQLite. So now, at the very least, if it is a Laravel issue, we've kind of reduced it down to something around the SQLite driver or the builder. I'm not sure yet. So now, okay, what I'm going to do is bring it back, phpunit, because we know the code is fine. So that means if I bring this back to SQLite,

or the builder. I'm not sure yet. So now, okay, what I'm going to do is bring it back, phpunit, because we know the code is fine. So that means if I bring this back to SQLite, we can dig a little bit further and see if we get anywhere at all, but I have no clue if we will. Okay, so we run the test again, and it should be back to failing. Now, the next thing I'm wondering is, is it somehow possible that the actual raw SQL that's being constructed is different in 5.6 than it was in 5.5? That's the next thing I'm thinking. So here's what I'm going to do. I'm going to go to my AppServiceProvider, and we're going to add this bit of code here. We'll say DB::listen for any kind of event that comes through. So this will basically trigger any time an SQL query is run. And what I want to do is just log to my laravel.log file the SQL. So I just want to grab the raw SQL that has been run. So if you want to take a look at this,

any time an SQL query is run. And what I want to do is just log to my Laravel.log file the SQL. So I just want to grab the raw SQL that has been run. So if you want to take a look at this, Laravel.log is in your storage/logs directory. So it's empty at the moment. But now every time we run an SQL query, we're going to log that query to the console. Okay, so let's give this a shot. We run it, and remember, as part of your test, we are going to run all of your migrations, and that's because we're using a database in memory. So that should build up everything. So let's switch back, and here's all the queries we ran to build up the database for our project. So here's what I think we're going to do. Let's do like a little git diff, or not a real git diff, but a standard file diff to see, are there any changes between what code is being constructed here? And if so, once again, we can kind of dig further down to see what the problem might be.

but a standard file diff to see, are there any changes between what code is being constructed here? And if so, once again, we can kind of dig further down to see what the problem might be. Okay, so this is the branch. This is the 5.6 raw SQL. So I'm going to copy that. Next, let's see if I do a git status here. Let's run a work in progress, and that's because, and real quick, that will add everything to the staging area and create a commit with a message of work in progress. We'll come back to that in a minute. But now I'm going to switch back to my master branch, because I want to do the exact same thing again and figure out, is this file different? Is there some change that I'm not picking up on? Okay, so once again, we have to install those older dependencies, and you can see how this is being updated. And then, unfortunately, once again, sorry, I forgot to copy this. We're going to have to

and okay, I am seeing something here. So let's go down there. So notifiableType is a varchar. It's still there, but then what's this notifiableID was before that. It looks like this is just reversed. That doesn't seem like an issue to me. And then the same thing. So that's notifications related. I can't imagine that's an issue. So let's go to this next one here. Okay, are there differences here? And now in this case, once again, it doesn't seem relevant, and I can't even tell what the difference is, period. So let's run it again. Now it's not saying anything, which means, oh, it looks like it's just a line break there. So that means, more or less, these two SQL raw dump files are exact. So I have no, I seriously have no clue what could be responsible for this. Let's talk it out once again. Specifically, when using SQLite, something related to foreign key constraints is not

I seriously have no clue what could be responsible for this. Let's talk it out once again. Specifically, when using SQLite, something related to foreign key constraints is not taking effect. And you know what? In fact, I bet we could even break this down further. Let's go back to that method, and yeah, let's just make it as simple as possible. When you're signed in, you have a reply for that user, you mark it as the best reply. Let's now say reply delete. Well, the foreign key constraint should take effect, right? And that means if I then die and dump the thread, get a fresh copy, and cast it to an array, here it is being set to null because we're on the master branch. So that part works. But once again, if we, let's get rid of that, check out our 5.6 update, all right, and I'll paste in this updated one, run it again, and it is working there. Oh, but you know what the issue is? We forgot to run composer install.

it's a point release, maybe they screwed up. But it doesn't seem related to that because I do a composer install and it stops working. So yeah, here's what we're going to do. Let's go to GitHub. We will discard that. And then actually on that note, you'll remember we had that work in progress. So let's just do a git soft reset. When you do git reset, you have soft and hard options. If you do a hard reset, that means I don't care about any changes that have been made since then, just bring it hard back to where it was at this state. If you do a soft, then you then you bring back the commit to how it was at that point, but you do not change any of the files. So it's a soft reset. So in this case, we can see here the files. I can discard that. We were testing. I can discard this section where we commented that out. Here, this is just auto formatting. I can discard that. And then once again, that's auto formatting as well. Okay, so now one final time if we run it,

this section where we commented that out. Here, this is just auto formatting. I can discard that. And then once again, that's auto formatting as well. Okay, so now one final time if we run it, it's fixed, but only in php land. And I fully intend to figure out what the problem is as soon as I finish this lesson. So now back in Safari, I'm going to go ahead and squash and merge all of this in. And then finally, let's go to that one section, add a comment. All right, so I will add the comment. And yeah, I think we're good to go. So give that a refresh. This is now merged and closed. And we are now running on Laravel 5.6.