A poll has these simple requirements:

A PollId, the primary key

A question id, the id of the currently displaying question

A question, the model of the currently displaying question

A list of Responses, initially empty

A boolean for isAcceptingAnswers, initially false

There are no views for this model.

void nextQuestion(int pollId, Question question) # Sets the next question to question

void haltRecievingAnswers(int pollId) # Sets isRecievingAnswers to false

string getAnswer(int pollId) # Returns the answer if isRecievingAnswer is false

void submitResponse(int pollId) # Submits a response to the response list if isRecevingAnswer

unit tests:

nextQuestion -> Does this successfully set the next question?
nextQuestion -> If the question has isRecievingAnswers at true, do we get an HTTP 400?
nextQuestion -> On a bad poll id, we should get a HTTP 400?

haltRecievingAnswers -> does this successfully set isRecievingAnswers to false?
haltRecievingAnswers -> if isRecievingAnswers is already false, we should get a get a HTTP 400?
haltRecievingAnswers -> on a bad poll id, do we get 400?

getAnswer -> Does this get the right answer?
getAnswer -> if isRecievingAnswers is true, we should get a get a HTTP 400?
getAnswer -> on a bad poll id, do we get 400?

submitResponse -> does this actually submit a response
submitResponse -> on a badd poll id, do we get 400?

The question model has the following fields:

QuestionId, the primary key

Prompt, a string question

AnswerOptions, all possible answers to the question

CorrectAnswer, the correct answer

A question is purely a model and there are no views for it.

We want to be able to consume Models and produce Models.

In essence, imagine you want an apple, and I pass you an apple. Then, when the apple reaches you, you get a bunch of random shit describing the apple, like "RED", appleCount: 1. This is pretty useless to us, because you wanted an apple and I just gave you a bunch of crap that describes the apple.

The serializer is all of the stuff that describes the apple, and Swagger is the tool that will allow you to get an actual apple from the serializer.

In reality, the backend will serve serialized objects, and generate this cool file called "swagger.json" which the front end will generate a bunch of code from to turn serialized objects into real JavaScript objects, effectively turning our backend Python Models to Javascript Models.

Further, Swagger lets us call the backend easier. Right now, if I want to call the backend I will have to make some HTTP request like curl 127.0.0.1:3000/Session blah blah blah. And in JavaScript code, I'd have to do the same thing but with JavaScript.
However, Swagger will create our own API for us, so if I want to GET something, I can do something like:
Api.View.Get()
on the JavaScript side.

"swagger.json" is generated through us basically writing comments (literally writing comments if you want do, but I like the decorator format more). We can call the generator like this:
python manage.py generate_swagger swagger.json
which goes through every single python file and creates the Swagger Api for our front end to consume.

So, our goal is to serialize all Django Models, and generate the swagger file.

• Add https://drf-yasg.readthedocs.io/en/stable/readme.html to the requirements.txt
• Serialize every model, and make sure to include the Meta class inside the models (its for swagger)
• On every instance of us doing a GET call, serialize the output THEN return.
• On every instance of us doing a 'DELETE` call, take in an object, deserialize it
• One every instance of us doing a PUT/PATCH call, take in an object, deserialize it

The beauty of the Django serializer is that everything is done for us, and all errors are handled by the serializer itself.

We shouldn't be using SQL-Lite (it's really just a temporary database Django has built in). Instead, we will switch to MySQL.

To do this, we need to create a Dockerfile that has our MySQL environment in it.
The username and password for the database should be set to environment variables, not hardcoded.

          We should create an answer model with a one to many relationship with Question

Originally posted by @bens-schreiber in #13 (comment)

Create a basic React Project, and also have a Swagger Client that can consume the back end to make our API.

The SessionService view:
(HTTP CREATE) void startSession(int sessionId, Question question) # Creates a Poll object in the db with the question

(HTTP DEL) void endSession(int sessionId) # Deletes the poll object in the db

This needs to be unit tested:
startSession() -> Does this create a valid Poll on the Session object?
startSession() -> If the session already has a poll, does it simply return 400?
startSession -> If the sessionId is bad, do we get 400?

endSession() -> Does this successfully remove the poll object and set the poll id and poll to null?
endSession() -> If there is no poll, does the request simply return 400?

The session view is responsible for creating and deleting sessions

The Session view:
(HTTP CREATE) Session createSession() # Creates a new session obj in the db

(HTTP DEL) void deleteSession(int sessionId) # Deletes the session obj in the db

This needs to be unit tested.

• createSession() -> returns a valid Session that exists in the db
• deleteSession() -> Can I delete a valid session?
• deleteSession() -> Will I get HTTP 400 if I try to delete a nonexistent session?

A response simply has:

A ResponseId, the primary key

A QuestionId, to which it belongs to

A string Answer

All fields are required, and there are no views for this model.

We should be able to post, get and delete sessions.

A session should consist of an ID, and a session owner.

The base most model for PollPall is the Session:

The SessionId is a primary key for the model

The name is an optional field, if not directly set to some value like "Foo Quiz" then it should be "Session {SessionId}" (ie, if Sessionid was 1 the field would be "Session 1")

A PollId, which is a nullable field, corresponding to the currently set poll

A Poll, which is a nullable field, corresponding to the currently set poll model

A Session is purely a model, and there are no views for it.