Endpoint "ListMeals"

[elli-hae]

This should resolve #81:

1. I fixed the downloadDailyDishes function in dish_name_download.go
2. I fixed the existing ListDishes Endpoint and renamed it to ListMeals. However, if there isn't a reason I might be unaware of for the project to have the terms "meal" and "dish" describing (seemingly) the same thing, I think it would be better to choose one and stick with it for consistency.

On a sidenote, I find the CanteenDates struct (a list of dishes/meals on a given day) to have a confusing name.

[tobiasjungmann]

This is great to get rid of the inconsistent naming and makes it more secure for cafeteria names! This can be merged, just to be sure: Why did you the dishtype in the query. As far as I understand, this results in different entries for the same dish if the type is changed. In my opinion it would be more consistent to only store the dish once and stick to the initial type instead of storing it again. An alternative would be to update the dishtype in the existing entry.

[CommanderStorm]

Thanks for the PR, from my side this can basically be merged

Regarding the question from the readme:

However, if there isn't a reason I might be unaware of for the project to have the terms "meal" and "dish" describing (seemingly) the same thing, I think it would be better to choose one and stick with it for consistency.

The eat-api does also talk about dishes. I think this was a typo/mistake introduced in the issue which nobody caught 😅

(src: https://tum-dev.github.io/eat-api/docs/#/menu/get__canteen_id___year___week__json)

I have pulled the change @tobiasjungmann mentioned into #325, as that should come with a db-change to reflect this ^^

=> I am going to revert the naming dish->meal changes to this branch and this is good to go

[CommanderStorm]

I am going to merge this via #326, as I can't push commits to this branch

[elli-hae]

This is great to get rid of the inconsistent naming and makes it more secure for cafeteria names! This can be merged, just to be sure: Why did you the dishtype in the query. As far as I understand, this results in different entries for the same dish if the type is changed. In my opinion it would be more consistent to only store the dish once and stick to the initial type instead of storing it again. An alternative would be to update the dishtype in the existing entry.

Hi, sorry for the late reply. It does indeed result in different entries for dishes by the same name and different types. The only example I found for this was the dish "Tagessuppe" which in the same cafeteria can be both "Studitopf" as well as "Beilage". As the previous (faulty) query selected for "CanteenDish", which is comprised of name and DishType, I decided to also query for the type (in case it might be relevant for prices, as "Studitopf" and "Beilage" have different prices). If the prices are unrelated it's definitely unnecessary though.

TLDR: I just tried to model it after CanteenDish, but it probably only affects one dish and even then is probably unnecessary.