Cafeteria Rating

[tobiasjungmann]

Cafeteria Rating

This implements the Cafeteria Rating System presented in Issue 50.
The new feature allows to save ratings for meals as well as cafeterias and query ratings as well as additional information.

The term "ratingNumber" is used to describe the actual rating like 4 out of 5; The term "rating" is used to describe the rating including the comment and all additional attributes.

In order to simplify and speed up the rating process with the best possible information, three different kinds of tags are introduced:

• Name Tags: Since the naming of meals is everything but concise (e.g. 12 different names for Chili con Carne in the last 3 years), ratings for meals with similar components are used to increase the amount of ratings for a specific meal. Each meal will be part of a category if the name includes a certain phrase. These phrases are defined in the json file MealNameTags.json.
• Meal Rating Tags and Cafeteria Rating Tags define attributes for a meal/cafeteria which can then be rated with a rating number. (e.g. clean 3; Queue Length 5; ...). These are defied in cafeteriaRatingTags.json/mealRatingTags.json and will be extended.

To reduce the times the average ratingNumber is computed for cafeterias and meals, this will be done periodically and the result will be stored in additional tables.

Cronjobs

averageRatingComputation

This cronjob computes the average of all ratingNumbers for all cafeterias, distinct meals in cafeterias and for all tags so that this data can be queried in every request without recomputing it every time. It only needs to run at daytime, since the majority of ratings will be created around lunchtime and most queries will take place at the same time.

mealNameDownload

This cronjob updates the list of available cafeterias and downloads all dishes in all cafeterias of the current week. This is the foundation to only allow ratings for actual meals.
This cronjob does only need to be run twice a week to load the meals for the next week.

Database changes

Every meal is stored with the name given in the eatapi. The cafeterias will be stored with the unique names from the eatapi (e.g. MENSA_GARCHING). The name of the cafeteria will mostly be replaced by the unique id in the table "mensa".

cafeteria_ratings

Stores the all the ratings for every cafeteria: including the ratingNumber, the name of the cafeteria, the comment and a timestamp of the creation of the rating.

cafeteria_ratings_averages

This table stores the average ratingNumber over all ratings for each cafeteria individually. Additionally, the best and worst ratingNumber as well as the standarddeviation are stored.

cafeteria_rating_tags

This table stores all ratings tags, which were added by users. each row includes the id of the corresponding rating as a foreign key, as well as the id of the tag and the rating number for this tag.

cafeteria_rating_tags_averages

Similar to cafeteria_ratings_averages the averages are periodically computed and stored in this table including the tag identifier, the average rating, the minimum rating and the max rating for each tag for each cafeteria.

cafeteria_rating_tags_options

This table stores all available tags to rate meals. Values must not be deleted, new values can be added by appending them to the corresponding json file and will be automatically inserted after the server is restarted.

Meal Ratings

The meal rating tables are very similar, with the difference that both, the meal and the cafeteria name/specifier must be stored.
The table "meals_of_the_week" contains all meals, the cafeteria where they are offered as well as their type.

mensa

Additionally, the existing table mensa is filled with the corresponding values and can probably be used to for the endpoint getMensa described in issue 7.

Endpoints

The description for endpoints with similar functionality are combined.

NewCafeteriaRating & NewMealRating

New Ratings contain a ratingNumber, the name of the cafeteria, potentially a meal, an optional comment, optional (either cafeteria or meal) Tags, an optional image (jpeg) and an optional list of tag ratings. This will also add the ratingNumber in the nametag table for all corresponding name tags. Only the parameters are correct, the entry will be saved.

GetCafeteriaRatingLastThree & GetMealRatingLastThree

Allows to query a certain number (specified by the limit) of ratings with all the stored information described in the previous section. Additionally, the average ratingNumber, the min ratingNumber, the max ratingNumber and the list of tag ratings are returned.

With the optional two given timestamps, ratings from a certain time span can be queried.

GetMealRatings is very similar, with the difference that a cafeteria and a meal (which is available in this cafeteria in this week) must be given. Additionally, a list of all applicable name tags with their average will be returned if meals are queried.

This endpoint will be renamed to GetCafeteriaRating/GetMealRating and it will be possible to query only ratings with a specific ratings (e.g. load all one star ratings for the "MENSA_GARCHING").

GetAvailableMealTags & GetAvailableCafeteriaTags

This endpoint returns a list of all available tags which can be used to quickly rate meals/cafeterias. It will return both, the English and the German name after the .proto file was updated. Currently, only the German name is returned.

Todo

• add new database definitions to the ddl in the branch db-models
• Second iteration of the .proto file to fix inaccuracies and add additional parameters I added in the implementation for more precise queries and results
• Store images
• integrate timestamps in queries
• prevent spamming (Won't be included in this PR)

Further ideas, improvements or criticism are always welcome! :-)

[tobiasjungmann]

Finally, all the feedback is implemented and the PR is again ready for review! It would be great if somebody could test it locally in order to prevent the "but it run on my device"-Issue: Therefore, the local client can be used to create some reviews in the database to reduce the effort.
Additionally, the PR's opened by the dependabot are directly included in this PR, since I had to update dependencies for the new endpoints.

[joschahenningsen]

Additionally, the PR's opened by the dependabot are directly included in this PR, since I had to update dependencies for the new endpoints.

Nice, I'll close them.

[joschahenningsen]

Did you have a look at the failing checks?

[tobiasjungmann]

Tests are passing now, thanks for the reminder, I've overseen them :)

[joschahenningsen]

🎉