Python-powered Chat Apps with Twilio and SendGrid Transcripts
Chapter: Using our database with the SQLAlchemy ORM
Lecture: Relationships between orders and users
Login or
purchase this course
to watch this video and the rest of the course contents.
0:00
Before we call our ORM model is completely done and move on from them. Let's just quickly follow up with one thing that we did touch on,
0:08
but we didn't finish, and that's our relationships, over here, I would like to come over here and say that this is a relationship and in
0:16
order to specify relationships, I need to go over here and import something else Will say from sqlalchemy.import orm, Now,
0:27
in the ORM, we can use that to define a relationship like this, and then we just specify the class name.
0:34
These relationships can be tricky because sometimes they speak in table name like lowercase users,
0:40
lowercase orders, and sometimes they speak in class or object terms. Right here. What we put is the class that we're related over to.
0:49
So we call this order, now, This user class kind of stand alone, it doesn't actually store any information about the orders.
0:59
It only has the fundamental ideas of the user itself. Remember, it has something over here that actually does have information linking them together.
1:09
So this is where we know this order belongs to a particular user. But what we can do is we can go over here and say,
1:16
This is an sa foreign key And then and here we put the name the column, again. Sometimes you speak in class terms.
1:24
Sometimes you speak in table database terms. This one we speak in database terms. So its users id not capital user, little case users. Plural, right?
1:37
So that says, there's a relationship between the order table and the user table, and the relationship is go back to the users table by the id.
1:44
Which is the primary key. Great, but we'd also like to have a friendly thing. When I go to order, I'd like to say .user and actually get the
1:54
user. And if I haven't loaded from the database SQL Alchemy will go and do a lazy load, a secondary query to pull that information up.
2:02
And that's this information right there. So again, this is a relationship. So we'll say from sqllchemy import orm. This one. We speak in class terms,
2:16
so it's going to be user like that. Now there's a relationship of final order. There's the user it belongs to. If I go to the user.
2:24
There's all the orders and it would be nice if I could say, If I happen to go user,
2:29
let's say order.user.orders, that that already is loaded because I've actually
2:35
done the queries on both directions out of the database don't need to go back. So what we can do is we can say these back_populate,
2:46
and then you say the name This one will be user. You say the name of the field over there. So here it's called User. So when we go to the orders,
2:56
it sets this object to point to that field there and similarly orders. Okay, now that should do it. Let's try to run our app and see what happens.
3:10
Looks like everything's fine. We go back to our database and I say, Refresh this. There's nothing changed about this right.
3:20
We should probably least have a key to represent the foreign key, and you don't see it here. What's going on? The problem or not really a problem.
3:27
It's just the way it works, is the challenges SQLAlchemy will never change a table once it exists.
3:32
No matter what you do to the class once the table exists, it's not going to make that change.
3:37
It wants to make sure like you don't to lead a column and it throws away data in production. That would be bad so we can use alembic and migrations.
3:46
And that's fairly complicated, really beyond the scope of this course. So what we're gonna do is a simpler style.
3:52
We're going to hit delete and rerun the app, that's going to come over here and recreate. Regenerate this if we go now and refresh this.
4:06
Hey, look at that. We've got a foreign key from user id over the users Perfect, and you can see the little key. The Blue key means foreign key,
4:15
this one. I don't think it has any changes in the database, but it's the orders that now have that foreign key relationship.
4:20
Alright, perfect. So quick Review. We went over and had our user id, and we upgraded it to a foreign key and then we use that foreign key to
4:29
define a relationship. We also wanted to make sure that if you work with one
4:36
we automatically set the values for the other case you kind of bounce back and
4:39
forth. So orders back populates user user, back populates orders and there we have it
4:45
I'm very easy way for us to work with the relationships between a user and it's orders.