Conversation
…int to utilize method
…t, creates migrations directory
| id = db.Column(db.Integer, primary_key=True, autoincrement=True) | ||
| name = db.Column(db.String, nullable=False) | ||
| description = db.Column(db.String, nullable=False) | ||
| moons = db.Column(db.Integer, nullable=False) |
There was a problem hiding this comment.
Is the idea here that even if some planet has no moons, we're still requiring 0 be added to the database? Totally fine decision! Someone might also say "let it be nullable and then querying the db for planets with no moons can check for null instead of 0". I could see either being compelling. If you think about what kinda of application might submit this data, say, from a "add a new planet" form on a web site, if you make the db field non-nullable, then the client would have to account for adding the 0 to the form data for planets with no moons, or, the server-side code would have to check for a moons value and add the 0 if there isn't such a value. Interesting food for thought.
| @planets_bp.route("", methods=["GET"]) | ||
| def read_all_planets(): | ||
| planets = Planet.query.all() | ||
| planets_response = [planet.to_dict() for planet in planets] |
| planets_response = [planet.to_dict() for planet in planets] | ||
| return jsonify(planets_response) | ||
|
|
||
| # @planets_bp.route("", methods=["GET"]) |
There was a problem hiding this comment.
Probably safe to omit commented out code from commits.
marciaga
left a comment
marciaga
left a comment
There was a problem hiding this comment.
Great job overall! Routes, model, and tests were well-structured 👍🏽
3 participants
No description provided.