Jose: Now that we've got the poll class,
we're gonna go ahead and write the option class.
So I'll open up the project, right click in here,
create a new option.py file, and then close that up.
And now we can get started with the option class.
It's going to be very similar to the poll class,
except it's gonna deal with the data
that an option deals with.
So here I'm gonna have written the initial code.
We've got the list import, the database import,
I've actually imported the createConnection function
from the connections.py file.
That doesn't exist yet, but we're gonna add it
in just a moment.
And then I've done the initial set up
for the option class.
An option takes in the text, the poll ID,
and it has an ID, then just sets them there,
and the repr() method returns the option text
that we can use to recreate an option object.
We're gonna need a save method as well,
there's again creates the connection,
calls database .option,
which doesn't exist at the moment,
but that just inserts a row into the database,
and then sets the self ID to be the option returned.
We're gonna add a get method,
so that we can pass in an option ID,
and it returns and option object.
For example, if we have to find a specific option
in the database, and then we also need
a couple of methods to deal with voting.
So I'm gonna add the vote method,
that takes in a username and is gonna cast
a vote for that username.
So all we have to do here is again
create the connection, then we're gonna
do database@poll_vote, pass that connection in,
the username, and self.ID
and this already exists so all we're using here is the stuff
that is already in our database.py file
and then we do connection.close.
Finally, I'm gonna add a property decorator
for the votes, and that is going to return a list
of database.vote.
What this is gonna do is again create the connection,
get the votes with the database.get_votes_for_option,
which it doesn't exist yet,
but it's gonna in a moment,
and pass in the ID of this option.
That's what we're gonna use to go into the database
and fetch those votes.
Then we'll close,
and we're actually going to return
those votes which again is a list of tuples,
it's not a list of objects anymore
because we've decided not to create
a model class for votes.
Let's open up our project
and we're gonna create a new Python file
inside there beside @.py, in database.py
I'm gonna call it connections.py
and all this is gonna have is a very simple function
to create a connection.
This we have to import from both poll.py and option.py.
So I'm going to go ahead and do that.
You can see that PyCharm is complaining from this import,
that's because we have to do models.option there.
So up to now, we've got everything
except the database.py changes.
Something important to note,
when we swap out from using the database
directly in our .py and now we're gonna
change all this to use the models,
is that the models are usually only concerned
with themselves and the data they can
put into the database and how they can use the data
from the database to affect themselves.
That greatly simplifies the thinking
for us as developers around these models,
but it can limit us when it comes to,
you know, using the database for its maximum efficiency.
That's why, now you're going to see
in database.py, we've got a lot of stuff
that simply deals with a single table.
We no longer are gonna have many joins, for example.
Database.create_poll just affects the polls table.
Database.get_poll_options just get options
from the options table.
Database.get_poll just uses a polls table, and so on.
Similarly in the options table,
it's very much the same stuff.
Database.add_option just adds to the options table.
Get_option gets from the options table.
Get_votes_for_option just affects the votes table.
You can see that there's not that many joins going on.
So, that is the trade-off that we make
when we use this models approach.
We lose power in the database side,
but we gain in maintainability of our code.
Let's start working on database.py in the next video.
I'll see you there.