Ich habe ein Entity mit einer Relationship (sorry, Kotlin, und Spring Boot ist 2.7.18):
class Pile {
...
@OneToMany(mappedBy = "pile")
@OrderColumn(name = "in_pile_ordinal")
@Where(clause = "consuming_operation_id IS NULL")
val materialUnits: MutableList<MaterialUnit> = mutableListOf(),
...
}
Jetzt habe ich einen Test der fehlschlägt, weil er ein Pile aus dem Repo holt (ganz normal mit getById), und ich bekomme zwei normale (und auch erwartete) Werte zurück und einen Null-Wert.
Jetzt habe ich keinen Schimmer, was ich da machen soll, das ist ja eigentlich ein Ergebnis, das JPA niemals liefern dürfte.
Hat jemand eine Idee, was man da noch versuchen könnte?
Es scheint so, als wenn eure Datensätze keine ID-Spalte enthalten.
Bitte füge mal eine ID-Spalte hinzu und im JPA-Service die @Id oder @GeneratedValue Annotation. Danach sollten in der Liste keine null-Werte mehr auftreten.
Sowohl Pile wie auch MaterialUnit haben IDs, MaterialUnit hat auch eine pile_id-Spalte für die Relation. Ohne das würde es überhaupt nicht gehen. Der kaputte Test war schon da, als wir noch keine @Where Annotation hatten, ich vermute mal dass selbige JPA aus dem Tritt bringt. Habe dazu aber nichts ergoogeln können.
Ich bin auch absolut sicher, dass der Fehler aus JPA kommt, Kotlin würde gar nicht erlauben, dass man Werte in einer Liste null setzt wenn der Typ „nicht nullbar“ ist.
Wie sehen die Daten denn in den Tabellen aus, die hier abgefragt werden? Relevant ist eigentlich nur die Tabelle, in der MaterialUnit persistiert wird und davon auch nur die Spalten pile, in_pile_ordinal und id.
Danke für die Antworten, durch die Anregungen habe ich das Problem jetzt nicht gelöst, aber ich habe verstanden, dass ich etwas prinzipiell falsch mache (das mappedBy = "pile" is Blödsinn). Ich denke, ich komme jetzt weiter.
Für mich ist nur überraschend, dass das bisher überhaupt irgendwie lief, und das hat mich davon abgehalten, meine Grundannahmen nochmal zu überprüfen.
Bist du meiner Vermutung denn mal nachgegangen? Oder behauptest du einfach, u. a. daran hätte es nicht gelegen?
Soll nicht unfreundlich sein und ich möchte die Lorbeeren auch nicht kassieren. Aber das ist etwas, was mich zum Beispiel auch am anderen Java-Forum massiv stört, dass Probleme nicht mehr benannt werden dürfen und korrekte Antworten deplatziert sind. Stattdessen muss alles umlabert werden … Das ist nicht meine Vorstellung von einer konstruktiven Debatte.
Wie wird die materialUnits-Liste denn eigentlich „zusammengestellt“? Das ist aus dem Snippet nicht ersichtlich, afaik.
In der MaterialUnit Tabelle gibt es ganz normal eine ID, also keine Duplikate. Das seltsame Verhalten bzw überhaupt das Funktionieren bei blödsinnigen Angaben ist dadurch zustande gekommen, dass eine alte Zwischentabelle, über die die Relation vorher lief, noch nicht weggeräumt worden ist.
Eine stinknormale 1:N Relation zum Laufen zu bringen, sollte nicht schwierig sein, und das hier im Forum zu machen, wo ich erst noch zusätzliche Informationen nachliefern müsste, ist meiner Meinung nach Overkill. Den Thread habe ich nur erstellt, weil ich mich durch das für mich unerklärliche JPA- Verhalten völlig verrannt habe und auch anderswo keine Infos dazu finden konnte. Die Antworten waren nicht direkt die Lösung, haben mir aber geholfen, meinen Tunnelblick zu überwinden, und damit hat der Thread für mich seinen Zweck erfüllt. Trotzdem kann ich gerne die Relation posten, wenn ich sie zum Laufen gebracht habe.
Man könnte sagen ich habe aufgegeben, JPA will einfach nicht richtig sortieren, vielleicht auch wegen der veralteten Version. Das Sortieren mache ich jetzt über einen @PostLoad-Hook, ist nicht schön, funktioniert aber verlässlich.