Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Es gibt getSingleResult(). In dem Fall muss das Ergebnis aber tatsächlich aus genau einer Zeile (nicht 0, nicht 2, nicht mehr) bestehen, ansonsten fliegt eine Exception.
EntityManager#find ?
Danke. Das werde ich am Montag ausprobieren.
Kein Problem. An einer anderen Stelle suche ich nicht anhand des Primärschlüssels. Da will ich mit ASC oder DESC sortieren und dann nur ein einziges Objekt holen.
An manchen Stellen verwende ich Repository. Da kann ich ganz einfach alle Objekte holen oder nur ein bestimmtes (anhand der ID). Ich möchte aber an manchen Stellen nicht das Objekt, sondern nur eine Spalte (im Beispiel aus Beitrag #1 ist das der String "value"). Deshalb verwende ich EntityManager.
Mit List<Object[]> zu arbeiten ist doch der Horror. Man benötigt irgendwelche "magic numbers" für die Spalten. Das macht nachträgliche Änderungen unnötig schwierig.
Java:
package my.playground.c3p0;
public record LayerRecord(Long id, String url, BigInteger vpos) {
}
List<LayerRecord> p = entityManager.createQuery(
"SELECT new my.playground.c3p0.LayerRecord(e.id, e.url, e.vpos) FROM LayerEntity e",
LayerRecord.class
).getResultList();
Möglich wäre theoretisch auch so etwas:
Java:
public <T> List<T> findT(Class<T> clazz) {
String constructorVariables = Arrays.stream(clazz.getDeclaredFields())
.map(Field::getName)
.reduce((s1, s2) -> s1 + ", " + s2)
.orElse("");
var p = entityManager.createQuery(
"SELECT new " + clazz.getName() + "(" + constructorVariables + ") FROM LayerEntity e",
clazz
).getResultList();
}
Bei diesem naiven und sehr generischen Ansatz muss die Projektionsklasse die gleichen Feldnamen haben wie die Spalten der Datenbanktabelle. So ist es möglich beliebige Spaltenkombinationen abzufragen.
PS: ich habe das nicht getestet, nur so aus dem Gedächtnis geschrieben.
Hm, hier ist die Frage: Was sind die Alternativen? Ich selbst habe in einem Projekt ähnlichen Code, denn Hibernate & Co waren für mich einfach zu lahm. Klar - das ist ggf. für Dich nicht der Fall, aber ich sehe, dass Du in einer Abfrage gleich mehrere Entities bekommst. Hibernate macht daraus mehrere Abfragen, was dann kritisch sein kann. Das ist aber nur eine reine Option - ich habe keine Ahnung, ob es so bei Dir ist oder nicht und die Chance darauf mag sehr klein sein.
Ich komme nur eben darauf, weil ich genau so einen Fall schon bzw. immer noch habe. Ich muss sehr viele Daten exportieren und wenn Hibernate da so zusammenhängende Konstrukte laden soll, dann werden da so viele Einzelabfragen gemacht, dass es "nie" fertig wird. Da bleibt dann nur die Möglichkeit, die Abfragen komplett selbst zu machen um da dann auch entsprechend optimieren zu können.
(So gab es dann bei mir auch noch die Optimierung, dass Daten erst in temporären Tabellen sammle um diese Daten jeweils als Ganzes einfach von Kopf bis Fuß zu laden.)
Und da hatte ich dann Code, der in etwa dem entsprach, den Du da gezeigt hast. Nur eben haben wir das in die Entity gesetzt, die Entities haben einen Builder und wir nutzen keine Ordinals sondern nutzen die Strings. Da mehrere Entities in einer Row sein können und sich Feldnamen überschneiden können, habe ich noch einen Prefix dabei, so dass man etwas hat wie:
Prinzipiell war ich am überlegen, sowas dynamisch zu bauen. Die Entities haben alle die Annotations wie @Column(name = ...) und so, aber der Aufwand diesbezüglich überschreitet die Aufwände, dies einmal selbst zu schreiben (bzw. eine KI dies aus den SQL CREATE Befehlen erzeugen zu lassen - ist ja reine Tipparbeit und die muss man nicht selbst machen ...)
Beim Zielformat habe ich übrigens dann den Code, der das automatisiert. Es werden halt Bulk Scripte erzeugt mit INSERT INTO Statements und da werte ich die Entities aus um Tabellennamen, Columnnamen, Discriminator Columns/Values, ... auszuwerten um dann dynamisch diese SQL Statements erzeugen zu können incl Unit Tests, die mich auf Veränderungen hinweisen (Ich habe eine Abhängigkeit auf die Entities der Neuentwicklung) und so ...
Also worauf ich hinaus will: So Code muss nicht zwingend falsch oder schlecht sein. Er ist heutzutage unüblich aber ich habe (teilweise schmerzlich) lernen dürfen, dass es da durchaus Notwendigkeiten geben kann
Wir haben auch Code, der Abfragen dynamisch zusammenbaut... Witzigerweise sitze ich aktuell genau an dem Refactoring von dem Mist. Dagegen ist der Code von @krgewb eine absolut saubere Lösung. Was mir allerdings nicht gefällt:
Wenn ich es richtig lese, dann hast Du auch keine Tabelle CAMERA, sondern ein Schema CAMERA mit einer Tabelle CAM.
Wie auch immer: wenn Du auf eine Spalte "zugreifst", die nicht existiert, dann sollte das zu einem Fehler führen. Anonsten wäre das schon ein "besonderes Feature" des DBMS, das ich mir schwer vorstellen kann. Auch möglich wären gewisse Datentypen.
Ich schaue nächste Woche in meinem Code nach, wie die Query aufgerufen wird und probiere nochmal herum, damit ich dir sagen kann, wo die Exception fliegt.
