Candidates for Code Smells in Peer Reviews

I see various code smells in Peer Review Branch

• Review Status is a string. Better would be an enum.
• Warum ist in der Review-Entity requestedBy die UserId, aber in der ReviewRating-Entity user der tatsächliche Nutzer? Besser auch in der Review-Entity den Nutzer verwenden?
• Reivew.requestedBy ist ein Long? Warum kein Link auf User?
• Likes.getUserId sollte eigentlich den User nicht die Id liefern (altbestand)
• Review.resource und Review.resourceId: wie hängt das zusammen?
• Review.resource ist in der Integrations-DB unique? Ist das Sinnvoll? Wenn verschiedene Autoren ihre gemeinsame Aufgabe zum Review anmelden, was passiert dann?
• Review.resource ist wohl die ExerciseId? Inkonsistent z.B. mit Statistics.exerciseId
• ReviewService.update ist sehr ungewöhnlich: Löscht erst alle ReviewRatings und legt sie anschliessend neu an? Das erste Problem ist, dass die ReviewRatings alle neue Ids bekommen. Ausserden ist das Update extrem komplex.
• Security: Jeder, der angemeldet ist, kann den REST-Service für die Review Info abrufen? Jeder kann Review Werte über den REST Service ändern?