2022-02-08 Bergauf aus der Messy Middle

Es fühlt sich diese Woche langsam wieder so an, als ob wir wieder etwas mehr Fahrt gewinnen. Das ORM-Framework nimmt immer mehr Gestalt an, mit unserem Deployment-Setup lässt sich uns unsere neue Core-Library einbinden und bald können wir uns dem eigentlichen Problem vom Juni widmen, mit dem alles begann, den Relationen.

Einen Nachmittag haben wir uns Zeit genommen uns zu überlegen, wie wir unsere DataAccessObject-Schnittstelle für alle Funktionsaufrufe vereinheitlichen können. Nach längerem Herumprobieren sind wir bisher zu folgendem Ergebnis gekommen:

Tree.find {
    fields { id, name }
    where {
        or(
            and(
                id eq 12,
                name eq "Tanne"
            ),
            id eq 24
        )
    }
    asc { name }
    desc { id }
    limit(123, 10)
}

Die meisten Deklarationen waren bereits aus früheren Implementierung vorhanden. Die längste Zeit ist in die Where-Bedingung geflossen. Hier sind wir uns auch noch nicht hunderprozentig sicher und probieren noch weitere Schreibweisen aus.

Zum ersten Mal sind auch Integrationstests entstanden, in denen wir in Transaktionen Funktionen auf den DataObjects aufrufen und somit nun einen durchgängigen Test durch die meisten Schichten haben. Lediglich die DataSource haben wir gemockt. Hier gab es noch ein kleines Problem. Die DataSource ist auf dem DataAccessObject zu finden , welches das CompanionObject in unseren DataObjects ist. Daher war sie für die Tests nur statisch verfügbar und konnte nicht für jeden Test separat gemockt werden. Um dieses Problem zu umgehen, haben wir einen DataSourceInjector implementiert, der eine DataSource ins DataAccessObject injecten kann. Da dieses Prinzip nur für Testzwecke genutzt werden soll, haben wir durch einen InjectorVerifier sichergestellt, dass nur injected werden kann, wenn ein gültiges Passwort mitgegeben wird. Dieses haben wir nur in unserer Testumgebung hinterlegt und prüfen im Produktivcoding gegen den gehashten Wert.

Letzte Woche waren wir noch auf der Suche nach einer Möglichkeit, transitive Dependencies, die in unserer Core-Library verwendet werden, auch in den verwendenden Libraries der Core-Library nutzbar zu machen. Dies ist uns mittels der Einbindung der Dependencies via „api“ statt „implementation“ gelungen. Wir sind also an einigen Stellen ein Stückchen weiter gekommen.