feature/models

[himanshuo]

Problem This feature creates the models that I need to make this successful. Some of these models are likely not necessary for now, but I will create them anyways.

Issue https://github.com/himanshuo/gameoflife/issues/26

Status

• [x] create golang object models for goals, tasks, player, fun cards
• [x] handle time for golang object models
• [x] handle json time for golang object models
• [x] constructors
• [ ] manipulation methods for Tasks
• [ ] use sprintf instead of current weird formatting [DEFERRED]
• [ ] doctype explanation of all methods
• [ ] no erronous spacing
• [ ] optimal runtime especially for database queries
• [ ] linters
• [ ] assertions should exist
• [ ] erronous input should be handled
• [ ] tests
• [ ] CR (mark as code review. Then go through diff and mark it up.)

[himanshuo]

learn about marshal and unmarshall for time.Time class and json: https://medium.com/coding-and-deploying-in-the-cloud/time-stamps-in-golang-abcaf581b72f#.kzqr7rfwj

[himanshuo]

having trouble with tests from json to time. i think it might be more prudent to go from time to json for tests for now.

[himanshuo]

Also, time.Time defines marshal and unmarshal methods already so I don't need to redefine those. Thus can just use time.Time instead of JSONTime

[himanshuo]

order of subtasks MATTERS. A given task can have steps A,B,C. Another similar task with different steps can be very different.

This is an edge case. But it's good to think about.

[himanshuo]

Should a task's SUBTASK field, show it's complete subtasks? Probably Not. You should simply link to subtasks. This requires creating marshal and unmarshal methods for a Task. This is more work, but it will allow for more fine grained control over what the resulting json and thus output to user looks like.

You can still use Marshal function for each specific type as you need.

[himanshuo]

given the slow progress, going to skip unmarshalling for goals subtasks because it is unclear whether that will be part of the use case. Likely, there will be some specific API endpoint which will take in input of task 1 id and task 2 id and just make task 2 a subtask of task 1. Thus don't need to deserialize the entire subtask. Endpoint could be: POST /task/subtask// or whatever. We will get to it.

[himanshuo]

Just going to make life simple for now and not include subtasks at all in marshal and unmarshalling. Going to only use what default json package allows.

[himanshuo]

I think at this point, I can go ahead and just use postgres. I am making the tables anyways.

[himanshuo]

It is good to split this PR with the DB PR.