Welcome back, everyone, to this lecture on creating models and fields.
In this lecture, we're going to be doing a couple of things.
First, we're going to quickly create a new project and application.
Hopefully this feels like review at this point.
Then we're going to check out how to register a database in the settings.
A lot of this is done automatically for us upon creating the project.
But I do want to show you where these settings are located.
Then we are going to run a migrate command to create the actual database that is using Python Managed
Up Pie Migrate, and then we'll create an example model with fields.
Now we're going to do is imagine that we've been hired by a dentist office to create some sort of software
for their office to keep track of patients.
And it would be really great if we could then store patient information in a database like their name
and age.
So clearly, we want to create a model called patient that has those two fields, a name and an age.
So to do this, we're also going to be exploring documentation as we go along, including the setting
up databases in the settings that pie page and the documentation, the different backgrounds that are
available.
It's actually a whole section of documentation about how to connect to different backgrounds and then
also the different fields that are available for general models.
There's an entire section in the documentation that lists all the fields available.
OK, now in the next lecture, we're going to continue with a further discussion on migrations, including
the Make Migrations Command.
So we'll discuss in a lot more detail how these migrations work in the very next lecture.
For right now, let's just set up the basics and get started.
Head over to my code editor.
All right, here we are inside of a folder called Jingle Lectures, it's on my desktop, it's totally
empty right now, so let's create a new project, a new app.
Hopefully, this feels super familiar to you by now.
Again, we just called the Django admin tool at the command line and then we can say Start Project.
And let's call this project my let's say site.
If you want, you can call it my dental site or something like that, but we're going to call it my
site again.
Note that creates this project level folder.
And then we have managed our pie inside of that and then settings, URLs, etc. I'm then going to change
directory into my site in order to access manage that pie.
And from there, what I'm going to do is create a new application.
I can do that with Python, Manage Stop Pie Start app and this application, we can call it maybe the
office application because it's just going to keep track of the patients.
It's kind of up to you how you want to separate the idea of the application versus the models associated
with that application.
It really depends on your website, the scope of the website, scope of the application versus the project.
And there's no real right or wrong answer here.
It just kind of depends on what you're thinking of.
So I'll go ahead and start that.
And now we have an office application.
OK.
With that being said, let's go back to my site and explore the settings that pie file.
So if you open up settings about pie file and you begin scrolling around through it, you'll notice
eventually there's a section called databases, and this is where you can actually set the database
engine, as well as the name or location of the database.
So there's two key things here.
One first is the engine.
By default, Django selects sequel like three, which is what we're going to be using as your engine.
Because Django knows that if you're using Django by default, then that means you have Python installed.
And if you have Python installed, then SQLite three came with it.
So Django knows for sure that you have SQLite three if you're able to use Django.
It doesn't necessarily know for sure if you have Michael or PostgreSQL, etc..
So that's why it doesn't include those, but we can easily swap out the engine.
We'll show you how to do that in just a second, but the name component is also an extension of the
base directory along with that SQLite three.
So essentially, what this is saying is inside your base directory.
Note that that was defined up here.
It's basically your current parent directory.
You can see you can build paths in the project with Base Directory forward slash subdirectory.
You seen me do this with the OS system just because that's kind of a more old-school way to do it,
but I prefer it that way.
But you can't technically also just say based directory, forward slash and then the subdirectory so
that it's also OK to build paths that way.
But can you see me do it with Import OS Joint Path?
But this is the way you can do it as well.
All right, so scrum are coming back down here.
We can see we have the engine and by default, the back end was sequel like three.
But let me show you in the documentation page.
If you go to this link on Settings databases, I want to show you what that looks like.
So let me bring in that link underneath settings.
So if you go to the Settings page underneath Django Project RT.com or Docs Django Project.
So again, here I am at Settings.
This is all the documentation that has to do with the settings that py file.
You can scroll down eventually until you get to the database section, which has to do with that.
So click on database and it says, OK, here's the default engine name.
But clearly, if you end up using other database back ends like Michael, PostgreSQL etc, you're going
to end up adding more information here.
For example, let's imagine you had already a PostgreSQL database set up somewhere.
Well, then you have to tell Django some information in order to interact with it.
So here's a very simple example, like adding in the name the user the password host port.
I should make a recommendation that typically you wouldn't just put in your password like this as a
plain string.
You would actually grab this from some sort of environment file, but more on that later.
You can also click on the engine link here, and that will take you to the string quotes for the engines
that are supported.
Like PostgreSQL, my sequence equals three and Oracle.
Keep in mind, these are the ones that are built in and shipped directly off Django, so you don't need
to worry about adding any external library.
Databases, however, are beyond just these for here in school, like three that actually supports a
lot more than that.
You just would need to install additional libraries.
And if you go to the databases section of the documentation, it has a lot more details on this like
PostgreSQL, my SQL, Oracle, etc. And then it says database back ends provided by third parties.
So if you click on that, these are more third party back end that they're technically not officially
supported right out of the box by Django, but they're good enough that Django includes them in the
documentation.
So things like Ms SQL Server, Google Cloud Spanner, Firebird, Cockroach DB, and there's even more
unofficial projects that things like MongoDB you can check out.
If you just do a Google search for Django plus MongoDB, you'll eventually find an additional library
that ends up connecting your settings up file to that specific database, as we keep mentioning.
If you're just starting out, you should really just start out on sequel like three and then maybe move
on to a sequel tabular database, and the instructions for connecting of those are pretty much all here.
So you can see there's different instructions on how to connect and how to name into these variety of
different databases.
And if you click on one of these, for example, let's say you're really interested in using PostgreSQL.
You would just go to the database documentation section, click on PostgreSQL, and it has the full
instructions on how to host, how to connect to it, how to save stuff in a configuration file, and
then more information on optimizing the configuration.
So there are a ton of links, step by step resources all here for you inside the documentation.
Now, as I mentioned, we're really just working on the stuff that's directly available for us right
out of the gate.
So that's we're going to be using SQL like three.
OK, so I know that was kind of a lot for the settings, but hopefully that gives you a better understanding
of how this is actually working on the back end.
This engine is already built into Django and there's other engines available for us.
And then this name is basically pointing where is the actual database?
Now you may be wondering, Well, this is saying it's underneath my base directory under that SQL like
three.
But if I take a look at my base directory, I actually don't see that database file.
And that's because we haven't actually run any migrations yet.
We would first need to run the migrate command in order to actually create this database.
And we've done this before one time.
And I mentioned last time we did it that this really had more to do with the database creation.
So let's go ahead and explore it inside my terminal.
What I'm going to do is I'm going to say Python.
Managed pie.
Migrate, I'm going to enter, and so you would notice that after this, what really happens here is
the Migrant Command is looking at the installed apps setting.
So we scroll up here and you notice we have the default installed apps.
We haven't actually connected the office up to be installed there yet.
But what this does is it takes a look at your default installed apps or any apps you add to this list,
and there's going to create any necessary database tables according to the settings that you had under
database settings.
So because we have the settings underneath SQLite three, you notice we now have this DB that sequel
like three, this is the actual database if you were to click on this.
You can't actually see this in an editor because it uses binary, so you can essentially think of this
as a bunch of ones and zeros.
It's not quite like that if you were to actually open this up.
But that's essentially the idea.
This is not something you want to open up and edit because the raw data files being stored in the database,
so you can't really interact with this file in the same way you can with others, but just keep that
in mind.
It is now created for us by the fact that we ran that migrate command.
It looks at the installed apps inside the settings and creates any necessary database tables.
So what we want to then do is be able to create our own models and then we would have to make sure that
that's registered underneath the installed apps so that we run this again.
We can actually create those additional tables.
So with that being said, let's open up office and open up models that pie.
So underneath my site office models that pie, I have my very first models that pie file that I'm going
to play around with.
So how do we actually create a model?
We use a class call and then whatever you want to call your model.
So again, these concepts are represented by Python classes.
But really, what's going on behind the scenes is each of these models is representing a table.
And then each field or attribute inside that model is then representing some sort of column inside that
table.
So we say class and I'm going to call this patient.
And then we inherits from models that model.
OK, so then it's up to you to decide what columns or attributes should a patient have.
This one's always kind of tricky because you want to try to get as much right as you can upfront, but
there's always going to be changes into the future.
So luckily, Django is flexible on that.
You can add more columns later on, but you always want to try to get as much information as possible
at the very beginning of your project, even if you don't end up collecting it.
So what does a patient have?
Well, we know a patient has a name and a first name or last name, et cetera.
So what we could do is say, I want a first name.
And then off of models, we end up having to call the actual field.
So there are many different types of fields, and this is another one where you just need a little bit
of experience to figure out what are the fields that are available for us, as well as what is the most
appropriate field.
So at this point, I would like to point out that there is a model field reference inside the documentation.
It's under models for its large fields.
Again, you could just Google Django documentation model field reference, but this gives you a list
of all the field options you have.
So you have things like an auto field that's an integer field that automatically increments available
to available IDs.
Then there's big auto field, so that's much larger integers big integer field.
So if you have really large numbers that you want to store, that could be useful.
Binary fields zero one.
Some of the most common ones are the character field.
So as you can imagine, this is for strings.
And if you would want to use this, then you can check out the extra arguments that specific fields
have.
So, for example, this character field has a maxlength and this is actually required, so you have
to decide what's the maximum length that we want this field to hold.
So he would then have to think, well, what's the maximum length the character's a last name could
have?
So again, maxlength is actually being enforced at the database level, and this is the sort of thing
that you really want to try to get right at the beginning.
So if you ever have any doubt, probably go larger than smaller, you don't want to accidentally put
a max length of two letters for the last name.
And then obviously someone comes in the last name Smith, and you're kind of screwed.
You have to go back run migrations, expand that constraint, etc. So these are the kind of things I
want to be careful of and try to think as far ahead into the future as you can.
Obviously, this is always easier said than done, but it's just something to keep in mind.
So clearly we have things like character field, which are relevant for strings.
We have things like date fields that'll be useful if we want to set up an appointment time, register
their last appointment, we could do that.
There's also ways to use auto now, which would automatically create a timestamp of the current time.
Maybe a button is clicked.
So those things are super useful.
A lot of this comes just right out of the box ready for you to use.
And then for ages, we're probably going to want to use some some sort of integer based field.
So there should be an integer field so we can see here integer field.
Also note that there's the ability to only have a set limit of choices with integers, but more on that
later when we actually talk about interacting of this.
But right now, we're just going to set up the kind of simplest integer field, which is just that integer
field.
You can also have a minimum value and maximum value.
So if we start thinking about ages, maybe we want a minimum value age to be like one years old or zero
years old and a maximum value to be like 120 years old.
That way, someone can accidentally put that there a thousand years old.
OK.
So there are a lot of different things that we can do here, but we're just going to keep it as simple
as possible in order to just understand the basics.
Let me close this off.
OK, so we're going to create a character field for this model first name attribute and for character
fields, we do have to define a maximum length.
I want to set the sequel to 30 characters.
It's up to you if you want to make this longer or shorter.
Obviously, as I keep mentioning, probably go more on the longer side just for future proof purposes.
Now we're going to say last name is equal to models that character field.
And let's also have this be a maximum length of 30, then let's imagine we also want to keep track of
the patient's age.
That's going to be equal to models.
Then we have to think, Well, what's a relevant field for an age?
Maybe integers are OK for thinking of age in years.
You kind of don't say someone is three point five four.
As far as years and age, so saying something like three years old or four years old, probably totally
fine.
So we'll say into your field and I'll just leave the defaults there later.
Now I did mention we will have the ability to add in constraints or validation factors.
For instance, maybe we want to make sure that the age is in between a range of zero and 100.
That way, there's no accidental typos where someone accidentally puts an extra zero on, say, someone's
a thousand years old.
How will we do that?
Well, later on, we're going to learn about something called validators, and there's a bunch of built
in validators that are super useful.
And what you end up doing is you essentially add them to the fields while you're building out your model.
For example, here's a custom validation field for Validate even, which is actually saying, Hey,
the number of Puddin has to be.
Even now, that's a little specific, but we can see there's a bunch of value validators that are useful
to us.
For example, a minimum value, any maximum value that would be really useful for something like age.
We're going to introduce validation later on because it has more to do with user input and then making
sure that that user input is correct.
And if not, it throws an error to the client user and then they can fix their error.
There's also a bunch of really useful validators, like an email validator to make sure this is an actual
email address.
OK, so more on that later.
But just keep that in mind that that will eventually come into play here.
But we want to keep things simple, so I'm just going to save those changes.
So what have we done so far?
Well, I've created a model and it has attributes which eventually I want to make sure that this model
is within my database.
But right now, we haven't actually connected this model to the database, so we need to run migrations
again and actually make migrations.
But that involves us connecting the application to the settings that pie.
Let's take that into consideration in the next lecture.
I'll see you there.