Diese Woche gibt es gar nicht so viel zu berichten. Wir haben etwas Brainstorming bezüglich der Challenges und wo es mit ihnen hingehen soll betrieben. Außerdem haben wir weiter am Umbau bzw. dem Split der Achievements in Challenges gewerkelt und neben dem Backend sind die Challenges jetzt auch das Frontend-Model vorhanden. Wir können uns jetzt die Challenges abholen und anzeigen, aber der Umbau der Contribute-Funktion erweist sich als schwieriger als angenommen. Hier müssen wir noch einmal zurück ans Board. Wir haben uns vorgestellt, dass man beim Abschluss einer Challenge ein Achievement erhält. Wir würden allerdings auch gerne vorsehen, dass für ein Achievement mehrere Challenges nötig sind. Hier stoßen wir mit unseren Iterationen über unser Model langsam an Grenzen und müssen uns demnächst über unsere eigenen Selects Gedanken machen. Eigentlich hatten wir bereits diese Woche das Vergnügen und haben uns darin versucht, sind aber schon an einem vermeintlich einfachen Beispiel gescheitert: Bisher hatte ein User eine Liste von Achievements als Relation. Als wir diese definiert haben, sind wir auf einen Lazy-Load-Fehler bei der Initialisierung gestoßen (wenn man dem Internet Glaube schenken möchte, DER häufigste Fehler überhaupt in diesem Zusammenhang). Um diesen zu fixen, hatten wir durch Stackoverflow-Suche auf den Fetch-Typ „EAGER“ umgestellt und mit einem Kommentar versehen, dass wir uns für die Zukunft eine bessere Lösung überlegen müssen. Jetzt war die Zukunft, denn als wir dem User eine neue Relation „Challenges“ spendieren wollten, haben wir festgestellt, dass sich nur eine Relation „eager“ laden lässt. Darauf hin haben wir etliche Versuche unternommen, unsere eigene Select-Logik zu hinterlegen, was für eine solch einfache Beziehung eigentlich ein Kinderspiel sein sollte, sind über zahlreiche Lösungen gestolpert, die nicht funktioniert haben und haben das Thema für diese Woche mangels Suchbegriffen ad acta gelegt.