Welcome back, everyone, to this lecture on models and databases.
Jingle models are defined inside a jingle app or project inside the model's top pie file, which is
a file we haven't actually played around with yet.
The model's class operates on a system which ends up directly converting the Python based code into
SQL commands that interact with that database.
This makes it much easier to work with the backend database because you just need to worry about writing
Python code.
Now, creating a single model is similar, it's creating a new table in a database.
For example, you can have your database, it's an SQL light.
And then you want to create tables that exist within that database.
For example, let's say we're running a website for a grocery store.
So we have customers or food items or employees.
Later on, we'll also discuss how we can create relationships between these tables.
For example, check if a customer actually bought a particular food item, and then we could make a
new table for something like orders and actually connect a customer to a food item using relationships
one to one one too many and so on.
We'll talk about that more details later on.
For right now, though, each database table has a name and then columns where each column will have
a specific data type.
For example, character strings would be that good data type for names of customers or integers.
Would it be a good data type for ages of customers in years?
So now let's explore how general models works in conjunction with these sort of structures.
So inside of your models, that profile, you're going to have an import line that says something like
from Django, that DB import models and then to create a new model which directly correlates to a new
table in your database, you create a class and then you get to decide what you want to call that particular
model or database.
And then you add in attributes which end up being fields in your model.
The attributes are analogous to columns in the table.
This, in turn, gets automatically converted to some sort of sequel command to the database to actually
create the table so we can see here.
This is direct conversion from your Python code and then this gets turned into SQL code that can then
interact with the database.
Again, you don't need to worry about that bottom.
You just need to worry about the Python code on top, which is much easier to work with.
Now, let's talk about a couple of key concepts for jingle models.
The first one is that it inherits from the built in models class.
So there's a bunch of methods that are available to you right off the bat from inheriting from models
that models class.
It also uses fields to define both data types, and sometimes some data constraints don't get a little
too confused on this because there are actual constraints classes within Django.
But you can think of the arguments for passing into the fields as also defining constraints.
For example, maybe you want to have a particular data type column or field require information like
a user's email address, in which case you can add a not null constraint, not know what would be the
terminology used in sequel.
But later on, you'll see that there's actually easy to use arguments you can pass in during the field
creation to put a constraint on it.
For example, if we look back here, the first name and the last name, we're constrained to have a
max length of 30 characters, and we can see here a character field was chosen for that particular attribute.
Another example could be maybe you want to require unique entries, like having a unique user email
so you don't have duplicate accounts, so you could add that on a face unique constraint.
Again, that unique constraint is more of a sequel syntax.
Instead, in Python, you would just say something like unique is equal to true, and we'll explore
examples of this later on.
So again, you end up choosing a field and then you can choose some sort of parameters or constraints
that have something to do with that field.
So we have the data type where the fields are chosen.
Here we can see a character field, which is typically a string field.
And then here we can see a max like a 30, which is just a constraint.
This first thing can only have up to 30 characters.
Again, it's up to you how long you want to make this sort of maxlength constraints.
And we can check out the documentation for a list of all possible fields.
And then within those fields, it gives you a list of all the possible arguments you can pass in.
Jingle models can then also be later on connected through keys.
So here we actually see two models a K two tables in the database being connected.
The first model is a musician class model.
And here we can see the musician has a first name, a last name and an instrument.
They're all character fields.
Now we can see they have a length constraint.
Later on, we also have a class album model.
And there we have an artist.
But notice the artist has to be connected later on to a musician.
So that is a direct relationship between the album and the musician.
We can also see that the album has a name, a release date, a number of stars.
So now we're seeing things like a character field, a deep field for dates and integer field for numbers
that is integers and so on.
So let's continue our discussion by exploring how to actually create a model and add fields to it.
Later on in feature sections will actually be able to drastically advance our tango abilities by automatically
creating templates simply by connecting them to a model that's known as class based views.
And it's going to be super powerful tool once we understand how to use models.
OK, I'll see you at the next lecture.