[MUSIC]
>> Where it comes to life is
where you actually start to think about
the data that you're working with.
In this case, we talk about destinations and then you can
see this funny syntax here that says int:pk.
Pk is the unique key for that instance,
that destination and int is the integer.
The way we've set up our database is that we have a table of
destinations and you describe
all your data tables in a models file.
In our case, we've got
this class called destination that inherits from
a Django base class called
model and you describe all the fields that you'd have on this.
Just to start with, you've got name and description.
Name is the CharField and description is the TextField.
Then you can put any constraints that you need on there.
When you're working purely with JavaScript, for example,
if there is a database that you are
backing off onto you'd have to do
all that client-side validation of is this the right length?
Does it have the right fields?
But you can do that in Django and express all of that in Python.
In the case where we've got a destination here and a description,
you can then also say,
if we have an object which relates to that,
for example, a space cruise.
It has to be going somewhere,
you'd hope it just doesn't fire off into space.
You can actually describe the relationships
between the different models that you've got in your database.
In this case, we say this cruise has got
actually many destinations that can
make many stops, which is pretty cool.
This is a many-to-many field,
and we'll call that relationship cruises.
When we get a list of cruises from the database
then we can see
both the destinations for
that cruise and also when you get a list of destinations,
you can also do a reverse lookup to see
what cruises are available on that for you.
This is Django's data model, I guess.
In terms of the fields that it supports it's got all the stuff
that you need for a basic web application.
You want to express an e-mail address you use that,
but If you want people to upload
images then there's an image field.
If you want to work with JSON data,
then there's a JSON field.
Everything you'd need for a web app is built into Django,
which is what is so cool about it.
As she does the hard work of translating
this Python file into a database for you.
Django works off this concept called migrations.
Once you've expressed the data that runs
the web application you
run another command called make migrations.
Django managed a py make migrations.
That will generate these migrations files
which you never need to look into but basically,
it's a file that expresses to
a system what needs to
exist in the database in terms of the structure.
These files will exist as migrations as a point in time.
Let's say you want to use Postgres as
the database server or MySQL or SQLite
is the built-in one then when you've build
the migrations you can
configure which database back-end you want to use.
Then you just run migrate and it creates
all the tables for you, all the structures.
It creates all the foreign key relationships
for the models that you've expressed.
Then when you basically want to then run your website,
your database is there and ready for you.
It automates all of that database management stuff which
becomes so tricky when you're working in production environments.
>> Okay. That's going to be my object-relational mapper.
That's going to be my ORM.
If we were going to put this into .NET terms,
that sounds an awful lot like Entity Framework,
that I can go in and I can describe
my schema and then Entity Framework is
able to create the database
and manage it and handle all of the updates and so forth.
Then what I'm also hearing from you is that my database type,
that could change, but I don't need to
worry about recreating my migrations.
I don't need to worry about recreating my data model,
that that's just going to work.
If I'm doing SQLite locally and I'm doing Postgres in production,
that all of that's going to behave the
way that it should without me having to do anything special.
>> Yeah, exactly. Yeah, if people are familiar
with Entity Framework and
I guess the migration model that that has.
Similar to a DACPAC.
It would create the migrations files.
They're not specific to the database back-ends.
If you do want to use SQLite locally,
SQLite is brilliant because it doesn't require
a service or server to be running on your local machine.
It's just like a plain text.
That's not even plain text it's
a binary file with a database inside it.
It's fairly performing.
It's good enough for local.
You don't have to run SQL Express Edition or anything locally.
You can just have this file with all the data inside
it and then when you deploy to production,
you can go all the way up to a Postgres cluster or SQL as well.
You can use Microsoft SQL Server with Django.
Microsoft that she maintains
a plug-in for Django that works with Microsoft SQL server.
>> I do want to go back real quick to the model.
Because one of the other big things that I noticed in
there is that there's also validation as well.
It's not just that you're saying that, hey,
this is a CharField or a CharField.
Current Char isn't quite
as heated of a debate
as a giff for jiff and by the way,
the correct answer is giff.
I'm willing to stick my place in the sand on that one.
But when it comes to like hard Char,
I find myself just flip-flopping back and forth.
Whichever it is that you want to pronounce it as.
But I noticed that you've got like
CharField and then you've also then got
things like max length and whether or
not it can be blank and so forth.
Is that going to be enforced only on the servers?
Is that also going to be enforced on the client as well?
>> There's different parts to
the enforcement working all the way from the database up.
If you say that this field cannot be null, so it can't be.
Blank could be just an empty string at a database.
It could also be null.
Some database engines depend on the database,
but some of them actually support null as
a field, as a field value.
If you say this cannot be null when it builds the database,
it will actually say,
in table, this field cannot be null
even if at the database level
you can't even put data into the table.
Some of the other more value-specific ones.
Max length, this would be
a varchar 50 field basically when it gets created or an varchar.
I can't remember from my head which one it would
be depending on which database back-end.
But it would actually create the tables with
those constraints for you
and then it also does another level which is that,
when you're submitting data through a form,
if you've created a client-side form and you've submitted data it
does server-side validation of the data.
It also does another level which is
that when you generate HTML forms in Django,
it adds some of the constraints to the HTML attribute,
so the input fields.
The input fields will actually have the max length
encoded into them. All that stuff's in sync.
Basically, that's the nice thing about it is that the HTML form on
the front end would have the max length on the input field.
The server-side validation that gets
run when you click ''Submit'' would check some of
those attributes and then the database has also got
both the length validation
as well as null validation and any other attributes.
It's not just length, blank, and null.
You can go nuts
if you want and do full reg access and stuff like that.
A common mistake people make is
they write a RegEx for e-mail and then only later
figure out that there's an e-mail
built-in which has got all that stuff for you.
But yeah, if you want to go
crazy with the validation you can do that.
You can also write validation functions in the model.
You can basically extend this class by
adding additional methods to it
which would do server-side validation when the form is submitted.
If you want to check that
the date of the cruise is not in the past or something.
You could do all that stuff,
but you can do that server-side in Python.