@@ -11,19 +12,17 @@ Hibernate OGM ist dazu in der Lage JPQL-Queries zu übersetzen in die Sprache de
## Aufgetretene Probleme
### Aggregatfunktionen in Hibernate OGM
Da Hibernate OGM ein laufender Prozess können bislang nur manche Sprachkonstrukte von JPQL in andere Abfragesprachen übersetzt werden. Was genau übersetzt wird unterscheidet sich je nach genutzter Datenbank. Die Version für MongoDB-Datenbanken unterstützt die folgenden Teile von JPQL:
Da Hibernate OGM ein laufender Prozess ist können bislang nur manche Sprachkonstrukte von JPQL in andere Abfragesprachen übersetzt werden. Was genau übersetzt wird unterscheidet sich je nach genutzter Datenbank. Die Version für MongoDB-Datenbanken unterstützt die folgenden Konstrukte von JPQL:
-simple comparisons using "<","⇐","=",">=" and ">"
-`IS NULL`and `IS NOT NULL`
-the boolean operators `AND`, `OR`,`NOT`
-`LIKE`, `IN`and `BETWEEN`
-einfache Vergleiche mit "<","<=","=",">=" und ">"
-`IS NULL`und `IS NOT NULL`
-Die booleschen Operatoren`AND`, `OR` und`NOT`
-`LIKE`, `IN`und `BETWEEN`
-`ORDER BY`
Im Projekt my-aktion wird an einer Stelle die SQL-Aggregatfunktion SUM genutzt, diese wird theoretisch nicht unterstützt konnte aber mit einem "workaround" dennoch genutzt werden. Die restlichen Queries konnten Problemlos weiter genutzt werden ohne spezielle Anpassungen vornehmen zu müssen.
Der unten dargestellte Code zeigt die Methode in welcher die Abfrage mit der Summenfunktion aufgerufen wird. Aus einem bisher unerfindlichen Grund funktioniert die Summenfunktion so obwohl diese eigentlich nicht unterstützt sein sollte. Der einzige Unterschied zwischen diesem und den anderen Methoden in der Klasse ist der dass anstatt über JPA-API direkt die Hibernate-Native-API genutzt wird.
Im Projekt my-aktion wird an einer Stelle die SQL-Aggregatfunktion SUM genutzt, in der Dokumentation werden diese nicht bei unterstützten Konstrukten aufgezählt, allerdings scheint denoch zumindest eine teilweiße Unterstützung für HQL zu bestehen. Näheres weiter unten. Die restlichen Queries konnten Problemlos weiter genutzt werden ohne spezielle Anpassungen vornehmen zu müssen.
Da im Code nur auf das Session-Interface zugegriffen wird und nicht direkt auf die OgmSession, sollte die Methode auch mit einer Hibernate-ORM-Lösung lauffähig sein, müsste also nicht angepasst werden.
Der unten dargestellte Code zeigt die Methode in welcher die Abfrage mit der Summenfunktion aufgerufen wird. Der einzige Unterschied zwischen diesem und den anderen Methoden in der Klasse ist der dass anstatt der JPA-API die Hibernate-Native-API genutzt wird und damit HQL anstatt JPQL.
@RolesAllowed("Organizer")
@Stateless
...
...
@@ -48,6 +47,23 @@ Da im Code nur auf das Session-Interface zugegriffen wird und nicht direkt auf d
Da im Code nur auf das Session-Interface zugegriffen wird und nicht direkt auf die OgmSession, sollte die Methode auch mit einer Hibernate-ORM-Lösung lauffähig sein, müsste also nicht extra angepasst werden.
Der Nachteil dieser Methode ist allerdings dass die reine Nutzung von JPA damit entfällt und somit nicht einfach auf einen andere Implementierung wie zum Beispiel EclipseLink umgestiegen werden könnte.
Die Lösung wurde auf der folgenden Webseite gefunden https://www.gregoriopalama.com/mongodb-on-wildfly-using-hibernate-ogm/
Nach weiterer Recherche warum das genannte funktioniert, obwohl gegenteiliges in der Dokumentation behauptet wird, konnten folgende JIRA-Einträge von Hibernate OGM gefunden werden.
Beide sind als erledigt markiert. Im ersten wird Support für die SQL-Aggregatfunktion Count hinzugefügt. Diese Änderung ist bereits veröffentlicht worden in der Version 5.4.1 (siehe zweiter Link) welche die aktuelle Veröffentlichung darstellt und die im Projekt genutzte.
Des Weiteren ist auf der ersten Seite die Aufgabe verlinkt die weiteren Aggregatfunktionen zu implementieren. Die verlinkte Aufgabe ist der dritte Link. Hier werden die restlichen Aggregatfunktionen implementiert wenn man sich den Github Link für den dazugehörigen Pull Request ansieht sieht es so aus als ob die Änderungen bereits veröffentlicht wurden.
### Organizer-Dokument
Da die Dokumente in einer MongoDB-Datenbank immer einen eindeutigen Identifier im Feld *_id* haben müssen, wurde in die Organizer-Entity ein Feld Id eingefügt welches das email-Feld als Identifier ersetzt. Damit dennoch sichergestellt wird das eine bestimmte E-Mail nur einmal vorkommt in der Tabelle, wurde an das email-Feld die Annotation @Column(unique = true) angehängt (siehe untenstehender Code).
