search

dkhwang118 / CIS560_F18-Project-RecipeManager

KSU - Fall 2018 - CIS560 - Database Project - ProjectTeam1
GNU General Public License v3.0
1 stars 2 forks source link

Project Invariants #12

Open dbramucci opened 5 years ago

dbramucci commented 5 years ago

List properties that should always be true before and after a method in our program.

dbramucci commented 5 years ago

A quantity should never be negative because you can't have -1 ounces of salt.

This involves checking for sufficient amounts of material prior to subtracting out material.

dbramucci commented 5 years ago

A recipe, pantry or shopping list should never refer to an ingredient that doesn't exist.

This should be enforced by database constraints and gui design.

laurel-thomson commented 5 years ago

A recipe, pantry or shopping list should never refer to an ingredient that doesn't exist.

This should be enforced by database constraints and gui design.

Maybe to start with, we should not allow users to delete Ingredients? I can see enforcing this invariant being a little tricky if we allow the user to delete Ingredients. We would need to first check to see if the Ingredients are used in any Recipes and ShoppingLists. An Ingredient in a ShoppingList is a bit simpler: we could just remove it from the ShoppingList. But removing an Ingredient from a Recipe would mess up the Recipe and we'd want to give the user a chance to replace it with something.

dkhwang118 commented 5 years ago

A recipe, pantry or shopping list should never refer to an ingredient that doesn't exist. This should be enforced by database constraints and gui design.

Maybe to start with, we should not allow users to delete Ingredients? I can see enforcing this invariant being a little tricky if we allow the user to delete Ingredients. We would need to first check to see if the Ingredients are used in any Recipes and ShoppingLists. An Ingredient in a ShoppingList is a bit simpler: we could just remove it from the ShoppingList. But removing an Ingredient from a Recipe would mess up the Recipe and we'd want to give the user a chance to replace it with something.

I agree that for now we should not allow users to delete/update ingredients. Add and Search should be the focus while we build things up in the beginning.

When we arrive at the issue later we can do a few different things to allow the user to update/delete ingredients, but I believe that when we get to that stage we'll also have to decide on how to update/delete recipes, shopping lists, etc. so we can standardize the way we handle update/delete from the database.

montgomerysamantha commented 5 years ago

I'm not sure if I'm understanding this correctly, but wouldn't we want to add new Ingredients to the database if they were mentioned in a Recipe or ShoppingList? For example, a user puts in a new Recipe with a couple of new Ingredients. So, the Recipe would be referencing a nonexistent Ingredient. For simplicity, I think we would add the new Ingredient(s) to the database. It would be a big hassle for the user to have to add every new Ingredient before adding the full Recipe.

Or maybe I'm missing something. Let me know.

laurel-thomson commented 5 years ago

It sounds like for now, we will only allow users to add Ingredients and not allow them to update or delete Ingredients. As far as the UI design for whoever works on #3, I would agree that we want the user to be able to add new Ingredients as they are creating a Recipe (not force them to first add the Ingredient in the Pantry form).

dbramucci commented 5 years ago

A recipe, pantry or shopping list should never refer to an ingredient that doesn't exist. This should be enforced by database constraints and gui design.

Maybe to start with, we should not allow users to delete Ingredients? I can see enforcing this invariant being a little tricky if we allow the user to delete Ingredients. We would need to first check to see if the Ingredients are used in any Recipes and ShoppingLists. An Ingredient in a ShoppingList is a bit simpler: we could just remove it from the ShoppingList. But removing an Ingredient from a Recipe would mess up the Recipe and we'd want to give the user a chance to replace it with something.

When I was saying that we should refer to non-existent ingredients I was thinking of something along the lines of a foreign key constraint. If a recipe refers to an ingredient that doesn't exist then the program may crash when it can't find an ingredient with the corresponding ID/what would the name to show be/how would we show the units of the ingredient if they aren't listed.

If/When we get to the point of allowing the user to delete ingredients we could first check if any recipes depend on it and if so grey-out the option / give an error showing what recipes and shopping lists use it. So they would know what to delete/modify first.

I agree that supporting deletion should be left for later and that auto-adding is a convenient style. Although, it might be nice in the future to confirm that the user wants to add a new ingredient and that they didn't make a typo for an existing one. An algorithm that is useful for suggesting what might be meant when someone makes a typo is to find the ingredient whose name has one of the smallest Levenshtein distances to what they typed. This would be an advanced feature though compared to just asking if they meant to add an ingredient and I'm happy with auto-adding as a starting point.