Adding a CMS to Your Flask Web App Transcripts
Chapter: Saving content to the DB
Lecture: Tour of existing DB layer
0:00 well, it's time to upgrade our CMS and make all the changes were making permanent
0:06 So far, I've been putting off talking about working at the database because I didn't want to really get it. Was details involved with what we're doing.
0:15 I want to stay really focused on just building the CMS side of things. But now it's time to start saving things beyond just in the memory.
0:23 While our APP is running, much of this application is already built on sequel Alchemy And so what I want to do in this short video is take a quick
0:32 tour of how things are structured already that we can just plug into that overall pattern and framework. First, let's talk about a couple of tables,
0:42 so we have a user table and we're modeling that with a user class. No surprise there with sequel alchemy. We have a shared based class,
0:51 and the way that a class represents a table in our database is that it derives from this class sequel Alchemy Base.
0:58 We change the name of the tables that we wanted to be singular and capital. We wanted to be the little case in users,
1:04 so we set that, and then it has some pretty straightforward stuff. But as an idea, that's a imager,
1:10 its auto incriminating. So we're not to mess with that. You just save something that automatically generates this primary key force.
1:16 Have a name which is notable, given email, which has to be unique. And it hasn't index because it's very common when somebody tries to log in that we
1:27 would say, What's your email? What's your password? Let's go find the user by email, so you want that to be super super quick.
1:35 What else we have a few other things is admin. I guess it's worth mentioning here.
1:40 And obviously, this is the flag that gets set in the database that indicates whether
1:44 or not you are allowed to access the CMS admin section in my default. New users are not admits, as you would expect,
1:53 right, so this is pretty straightforward. One. Let's look it, probably the most complicated thing we've got going on here
1:58 which is the package. It's when you run the site and you look at all the packages. That's what you're seeing.
2:06 So we've got the name of the package being the primary key in this case, and some other staying there stuff like this.
2:12 I guess it gets interesting down here where we have a relationship between the releases for a package and the package itself.
2:20 We also have this cool, multi layer order by so first order by the major version than the minor version than the build version and back.
2:28 Populate the package link on individual releases as you bring him in. So you don't really need to know a whole lot about all of these things were
2:36 not going to do too much with it. But I did want to show you a few things that are in place.
2:40 Also notice that were using type annotations on the columns. And this is overriding what the standard type checker would think.
2:50 Oh, this is a column or their relation, Yes, but at runtime, what it really looks like is a string and a
2:57 list of releases. So we're going to tell Python that's what those are, and that will give us a little bit better helping the editor.
3:03 Right. So there's two exemplar tables or classes models. You also will see this thing called DB session.
3:11 So over here, what we're gonna do is we're going tohave initialization function that gets
3:16 called right at the start up of the APP and what it does is basically, it comes down here, and it checks to see if there is a database file
3:25 specified. And then it's going to create a sequel, light database or open the one that's specified in the file sequelae.
3:33 Right here is the file. Sequelae is really nice because it's already built in the Python. You don't have to install anything.
3:39 It doesn't run as a separate server. Just run your process and it run your Web app in ages, talks to it. That's super cool.
3:47 He probably wouldn't use it for riel Professional Web APS. For those you do something maybe like post GREss or maybe even Mongo DB.
3:54 But for now, it's equal. Light is working great, and we're gonna come over here, set it up and say, create all the tables based on all of the models
4:04 that you have seen, and then it just records. It's initialized, so that's pretty cool. The other thing is, when it's time to talk to the database,
4:11 we have to create a session. So we're gonna go over here and call this function Gonna create session,
4:16 set a little typing to help things get a little bit better because normally the tooling can't figure out what the's session things are.
4:22 Were also allowing you to work with objects after they've been saved to the database. That just makes things easier for us.
4:30 Final thing. We have this different locations where we have to make sure we've loaded all the models before we try to interact with sequel alchemy.
4:40 One clear example is right here before we say create all the tables. It has to be that we've loaded every single model into memory.
4:49 How do you know for sure that you've done that? Maybe pretty clear here, but over in the Olympic world, we also have to do that.
4:55 And that's not really part of this project. It gets a little more tricky.
4:58 So we've got this thing over here where we're just explicitly stating every file we're using every module that has some secret alchemy classes.
5:06 So when we add like a page, we're gonna come over here and have a, you know, pages or whatever we call it,
5:13 and I will make sure that sequel alchemy knows about that class, and that should create tables and start working with it.
5:20 This allows us to just put this in one place and not always think about how we're getting back to it. That's it.
5:25 I guess we could look at one example of using it. Let's go over here to say the user service,
5:30 So it's really quite straightforward. If we want to know how many users are in our database going to create a session and then we go to the session,
5:39 we say We want a query based on this table or this class, this model users We want to just count how many users that are.
5:46 So this is going to return a number, and we always want to explicitly close the session to make sure it's closed up right
5:51 away. And we can do that with a try finally find when we're creating the user. They were to create the user object,
5:59 get the session, had the usual call commit and then close it and then return the user. This part right here is where that expire on commit equals.
6:07 False becomes really, really handy. All right, so using this is not hard,
6:11 but you do want to fit into the existing design patterns and way we've structured stuff with our models and seek welcome and so on.
6:19 So now you know all about it. Hopefully, you like how we put it together.