I think we'll next move on to database seeding and Eloquent model factories. This is pretty great. So, when you are working on a new project locally, you'll want to set up a bunch of sample data. In the case of Laracast, well, I would want a bunch of dummy lessons and episodes and series. Now, how exactly do we go about doing that? And the answer is through database seeding. So if we scroll up, we don't have a generator for this, but we do have a command php artisan db:seed. Let's see how that works.

So if we scroll up, we don't have a generator for this, but we do have a command db:seed. Let's see how that works. Well, within a new project, if you go to your database/seeds file, by default you'll just see a single DatabaseSeeder. Think of this as the parent class that is responsible for triggering all of your seeders. And you'll see we have a little comment here. So why don't we create one ourselves? DatabaseSeeder UsersTableSeeder. And I believe I have a little snippet here, seeder, and I do. But it's pretty basic.

And I believe I have a little snippet here, seeder, and I do. But it's pretty basic. We extend Illuminate\Database\Seeder and we add a run method. That's all you have to do. So now, within here, you can do whatever you need to do to populate your users table in the database. Now, in the past, people might defer to the DB facade or they might reference their User class directly. So you might have something like a for statement where you say 50 times, I want to call User::create, and then you pass in the data.

So you might have something like a for statement where you say 50 times, I want to call user create, and then you pass in the data. But we can actually make this quite a bit easier in Laravel 5.1. In fact, it's as easy as this. We want to build up a factory for a User 50 times, and we do want to persist that to the database. Done. So now, if we go back to our database seeder, I will uncomment this, and I called mine UsersTableSeeder. All right, so let's try this out.

table seeder. All right, so let's try this out. And by the way, do note that I've specified that we want an SQLite database, and I ran the initial migrations, which means this should work, php artisan db:seed, and we're done. Let's take a look. storage/database, and select * from users, and we should see 50 random users. Now, tell me, how cool is that? But now, if you're anything like me, you're probably thinking, well, how the heck did Laravel know that, for example, right here, well, we're looking for names, or right here, we're looking for email addresses?

Laravel know that, for example, right here, well, we're looking for names, or right here, we're looking for email addresses? And the answer is through a factory definition class. And this is stored within the database factories folder. And you'll see that one comes straight out of the box. Now, take a look at this syntax here for how we define factories. Think of this as the blueprint for what a User might look like. So we call factory define, we provide the name of the class, and then we have a callback function that returns an array that describes the table columns. In this case, we have a name, email address, password, and the rememberToken.

function that returns an array that describes the table columns. In this case, we have a name, email address, password, and the rememberToken. Now, here's what's cool, a faker object will be passed to the closure here. And if you're not familiar with faker, think of it as a nice and simple API to generate any amount of data, whether you need a name, or an email address, or a paragraph, or a sentence, or an address, or a hundred different things, which means not only will the data you generate be random each time, but it's also a lot faster. So notice for the name, we just defer to faker->name. And just have a look at faker's documentation on GitHub, and you can see all of the various properties and methods that you can call.

And just have a look at faker's documentation on GitHub, and you can see all of the various properties and methods that you can call. But it's pretty intuitive. So you want an email, run faker->email. For a password, there's not a password property, at least at the time of this recording. So you could do something like this, or you could even do bcrypt($password). But now that begs the question, what about if in some situations you want to override this blueprint or these defaults? Here's how you do that. If we switch back to our users table seeder, when you call create, or there's also a make

Here's how you do that. If we switch back to our users table seeder, when you call create, or there's also a make method which will create the User models, but it won't persist them. So that's a good one too, especially for the purposes of testing. But yeah, for database seeding, you'll almost always use create. Anyways, we can pass an associative array here that will override the defaults that are specified here. So for example, if I always want the name to be John Doe, then we could do this. Let's try it again. Let's clear that within a new tab.

Let's try it again. Let's clear that within a new tab. I'm going to run it again. And this is going to show another thing we need to fix, but real quick, that's done. So if we do a select * again, now you'll see the rows all have John Doe as the name. But now if I scroll up a ways, notice that it still has the original data. So our goal was to create 50 Users, but now it seems like every time we run php artisan db:seed, it just adds 50 more. It doesn't truncate the table, which is really what we want to do. So here's what you can do in those situations.

It doesn't truncate the table, which is really what we want to do. So here's what you can do in those situations. Within your database seeder, right here or within a method, you could do something like this. DB::table('users')->truncate(); Or in reality, you'll probably be seeding a lot of tables, so you might do something like this. protected function truncate() or something like that. And then you can just update an array each time you add a table. Then you could say foreach $tables as $table, then do something like this.

And then you can just update an array each time you add a table. Then you could say foreach to truncate as table, then do something like this. Okay, so now when we trigger this, we'll clear out all of the tables in our project. So now if we were to run that again, and if we switch back and do another select * , you'll see that we cleared out everything and we once again have 50 rows, which is exactly what we want. Okay, so why don't we finish up by doing one from scratch. The users table and the user factory is already included out of the box in 5.1. So let's do another one ourselves. Why don't we stick with what you see at Lerikast?

So let's do another one ourselves. Why don't we stick with what you see at Lerikast? We have lessons. So I need a lessons table, a Lesson model, and then we also need a LessonFactory and also a LessonSeeder if we want. So the first step is php artisan make:model Lesson --migration for Lesson, and I do want a migration for that. Okay, cool. So now, yes, we have our Lesson model, and we should also have a create_lessons_table migration.

So now, yes, we have our Lesson model, and we should also have a create_lessons_table migration. I'm going to keep this pretty simple. We'll have a string for the title, and we'll also have a text field for the body. And you know what? Why don't we do one more for the published_at field? So timestamp published_at, and that should be enough. Okay, so I will run php artisan migrate. We have our lessons table. We have our Lesson model.

We have our lessons table. We have our Lesson model. So now I want a LessonsTableSeeder. DatabaseSeeder LessonsTableSeeder, and we'll set that up. And when we run this, once again, I'll say I want a factory for App\Lesson, and we want 50 lessons as well. But now within our parent DatabaseSeeder, if we were to call that, and let's update our truncate array, if we were to now run this php artisan db:seed, well, let's see what happens. Well, in fact, two things in this case.

what happens. Well, in fact, two things in this case. The first one is it can't find the lessons table seeder, even though we know that we created it. And that's because within your composer.json file, the database folder is the only one in a fresh layer of our project that isn't loaded with psr-4. It's just a traditional class map. So that means when you change or add a new file, you need to rerun composer dump-autoload. This is pretty basic stuff. So if we rerun this, but now if we still run this, well, it's not going to work like we

This is pretty basic stuff. So if we rerun this, but now if we still run this, well, it's not going to work like we expect. Let's try it out. sqlite storage database, SELECT * FROM lessons. And yeah, we don't get anything. And of course, if you think about it, well, we haven't described what the lessons table looks like. So that's why you need to go back to your model factory class. And you can add more here, or you could even create other files if you want.

So that's why you need to go back to your model factory class. And you can add more here, or you could even create other files if you want. So let's get rid of this, add a new one. And we're going to define the makeup of a Lesson or the blueprint for a Lesson. And if you remember, we have a title. We also have a body. And then we have a publish stat. All right. So with title, well, we can use just a faker sentence, very basic. For the body, we could say faker paragraph.

So with title, well, we can use just a faker sentence, very basic. For the body, we could say faker paragraph. You could either use, you know, Carbon::now() if you want, or you could use faker and call the dateTime method. And that would do it. Okay. So now let's try this out. Just for a recap, in our lessons table seeder, we've specified that 50 times we want to create a new record within the lessons table. And as for the makeup of what a lesson looks like, well, we created or defined the definition

a new record within the lessons table. And as for the makeup of what a lesson looks like, well, we created or defined the definition right here. And that should do it. So let's try it. php artisan db:seed. We'll give that a second. And now that should do the trick. So if I do a SELECT * FROM lessons, we should now have 50 dummy rows in the database. And if we take a look, we do.

So if I do a select * from lessons, we should now have 50 dummy rows in the database. And if we take a look, we do. Okay. So that's going to do it for the database seeding lesson. There's actually more to talk about when it comes to model factories, but that would relate a little bit more to the process of testing your application, which we aren't focused on in this video. So with that out of the way, let's move on to something else.