Database Seeder Update
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
Already have an account? Sign In »
Hi. Welcome back to Module five. This is less than 5.4 database Cedar Update and this lesson we're gonna implement the seating process in a way that supports composite keys.
So Larible does not natively support composite keys. This could be fixed with some additional PHP programming, But this is a sequel course. So we're gonna try to keep the PHP programming components pretty light locally. The way that we handle this isn't too bad.
Within the factory fouls the I d field must be a model count plus one function call. So we're gonna count the number of records in the model database and we're gonna add one to that number, and we're going to use that as the i d.
The I d field will no longer auto increments. So this is why we must use this method.
The school I d must be added is a field and we're going to select a random school much in the same way that we selected random models from other database tables
within the migration files. We must remove the big increments I D column on. We're going to replace this with another I d column. That is a big in urge er with no auto increment ing.
We're also going to add a school I d reference
within the cedar fall. We're going to use concurrency calls on all except the school creation.
And if you as you move through this, you may want to move one file at a time, being sure that test that one file as you move through all of the files. This will help you avoid being overwhelmed by a possible heirs in all the files if you try to edit them all at the same time and then test them all at the end.
With that said, let's move on to the programming environment
and see what this looks like.
All right, let's get those composite keys implemented. As you can see from the diagram, I've already implemented the composite key on many of the tables. I've done this to shorten the length of this video.
If we were going to walk through the implementation on all the tables, it would be repetitive, and it would also increase the length of lesson from 20 to 25 minutes, or maybe two or three videos.
Now, with that said, we're still going to walk through the implementation of how it was done, and I'm going to also go through them implementation of the last table. Now let's go ahead and get started. If we go to our shared folder and go to the database cedar file,
we'll see that I've switched all of the factory calls except the very first school call to concurrency function calls. And that is because when we switched to using a composite primary key lay arable doesn't actually support that.
Or at least it doesn't support it very well. We have to take the automatic increment ing away from the tables and the room, and then we got to do a count of the class and see how many are out there and then add one to that number, and that becomes the I D that we generate ourselves.
So let's take a look at what that looks like.
It sounds worse than what it actually looks like. So if you go to a factories and let's just go the 1st 1 which would be building,
go ahead and open this one,
you can see that I'm rolling an I D from building all count plus one
So this goes and accounts all the buildings, adds one. To that count, we assign that to a variable called I D. We then use that I d. As the idea on the table when we inserted. And that's also why we got to do the concurrency call. Because if we don't and we try to use a regular factory, call
some of these air going to generate the same count because they're going to be running on multiple threads or processes and they'll come back with same number and cause a failure. And that will be random, which means you could actually get it to work a couple times before it actually fails.
And, of course, we're doing the school and random order to get the I. D.
So from the building you can see how this has been implemented.
We have the school
from a random school,
and then we have the I D being generated from a building all arrow count, plus one. Then we use that as the I D.
Now let's go look at the table structure because the table structure has changed, too.
you know, before we do that, let's just see how different. One of these other factories is from the building factory. They're all pretty much the same implementation. We're getting a school
and we're getting an I. D. This room is from before
and we ah, that's for a foreign key constraint. And again, we use the idea in the same way
and the school in the same way.
Something to be careful off when implementing these is to make sure that if you copy and paste that you change the calling class
to what you're using it for. For example, if I copied this from building and then forgot to change the
the building keyword to course keyword, then I would be actually counting buildings and making my i d based on that.
And then also, we have to make sure that we include
the resource is that we are using. So school, for example, has to be included in the files.
And most of these factories
or all the factories, are the same thing. It's the school I d and the I d being generated in the same way.
let's go ahead and take a look at a table because we had to change the table migrations as well.
So if we look at the my gracious folder and let's go back to the buildings concept and I'll open up the table for that,
we can see that I've switched the big increments to a big manager
with an i d. For the column name and false. True.
Now this is a way to control the way that the I. D column is handled so false means it will not automatically increment
and true means it's unsigned again,
so that's very similar to just putting this on the end.
So on all the tables, we switch out the big increments with the big image er
with I d false. True, in the exact same way.
And then at the bottom,
we add this call, which is Table
array because of the square brackets and then i D
and school I D. And again, this is same for all the tables as well.
And the big thing when you're implementing these is don't forget your semicolons.
Make sure you get the names correct
and on the factory's you'll want to make sure that you include the models that you reference,
and you definitely want toe make sure you get the verb ege right here. If your copy and pasting from other files these files of will be available for download as well.
So let's go ahead and go through this process for the last file that I have
to ah, make reflect the composite key.
So in my backup folder, I still have the users courses table.
So I copy or I cut all of my files into a backup
folder. And then I moved them out one by one, fixing them one by one and running the migration and the sea process one by one. That way, if I had a problem, I knew which one file it. Waas
and I wasn't over burning by numerous airs. If I tried to change all the files at the same time,
we'll go ahead and
Go back one directory and paste that out
and I'm gonna go ahead and open this.
Okay, so this is the table creation. So I need to switch this big increments I d. With what I was using on the other ones,
which is this table big imager.
And again, that true, false, true
or the This is the column name.
This means that it will not auto increment.
And this means that it is unsigned.
And then I need to
copy this table primary call out.
And I just need to pace that up
the bottom of the columns
and saved that.
Now let's go and take care of the factory.
We're going to my factories
and user Course factory
is right here
when open this one
and in here, I need to
return my own I d and return a school I d.
So I'm going to need these two lines here,
and I need to change this to
user course. That's the model we are dealing with.
And I also need to make sure that I include the using statement
Okay, And then, of course, I need to
put those as the columns that will be inserted. So I d
We didn't have to do I d before because auto incriminating. But now it is not. So. We have to tell it what I d to use, and we need to not forget the common I did that a couple times
and then school
underscore i d
and I think we will be ready to go ahead and run that
migration and hopefully we don't get any errors. But if we do, we'll fix it.
You can see that I got an air appear above and the problem was that I forgot the column or the comma right there on the I D.
That's common. That's why it's a good idea to move one file at a time or two files at most. And then you can fix the errors incrementally instead of being overwhelmed. If all your files have errors.
beach be partition,
my great fresh. So we got a really and Stan, she ate all the tables.
I'll just sit up,
And we didn't get any heirs?
And now we're gonna run the seeding process. Well, actually, let's check the database. Cedar. Make sure that set up.
I need a uncommon the user course truncate,
and I need to Owen comment the use, of course. Concurrency creation.
Now, when you go, if you go through and you implement these one by one, make sure you comment out the ones that you're not using when you run the migration.
when I started this at the very beginning.
I was just working on the factory of the school.
I had all of these count. All of these commented out except for this school
like like this
because if I try to use that resource when I'm not working on it,
I could generate airs. So it's
and then I would uncommon one
as I went along.
But we're on the last one, so I can uncommon all of those.
It's faster. If I hold Ault and I slide my mouse down, I could edit multiple lines at the same time. I'm going to save that now. I'm gonna run my DB Cedar class
on. Hopefully we do not get an air
and it looks like it completed successfully. Let's go in and take a look in the database.
So I'm gonna refresh this
on the diagram. Changed user courses, air there.
I d school idea
So we can see that this user
belongs to this school
and this user belongs to this school
and some to keep in mind when we have this composite key is that within the user, I d. We could have to
number 46 is at different schools, but we couldn't have two of the number 46 at the same school.
All right, now that that's done, let's go ahead and head over to the summary, and that brings us to the 5.4 database. Cedar updates summary. So what did we do in this lesson? What we reviewed the factory file changes, and those changes include a concurrency call in the Cedar File. We added a school I d reference,
and we added an i D field as the
I. D Field no longer auto increments. We also reviewed the migration file changes. We removed the big increments. We replaced it. We replaced it with an I D. Feel that does not auto increment. And we also added the composite primary key,
and that completes this lesson, and I hope to see you in the next.
Transactional Procedure Part 1