6 Fragen zu Hibernate

Die Einstellung „Hibernate like Soft Off“ im BIOS bezieht sich auf das Verhalten des Computers beim Herunterfahren oder Ausschalten. **Bedeutung:** Wenn diese Option aktiviert ist, verhält sich der Computer beim Ausschalten (Soft Off, also S5-Zustand) ähnlich wie beim Ruhezustand (Hibernate, S4-Zustand). Das bedeutet, dass der aktuelle Systemzustand (geöffnete Programme, Daten im Arbeitsspeicher) auf die Festplatte geschrieben wird, bevor der Computer komplett ausgeschaltet wird. Beim nächsten Einschalten kann der Computer diesen Zustand wiederherstellen, ähnlich wie beim Aufwachen aus dem Ruhezustand. **Unterschiede:** - **Soft Off (S5):** Der PC ist komplett aus, keine Daten werden gespeichert, ein Neustart beginnt von Null. - **Hibernate (S4):** Der PC ist aus, aber der RAM-Inhalt ist auf der Festplatte gespeichert, sodass der vorherige Zustand wiederhergestellt werden kann. **Fazit:** Mit „Hibernate like Soft Off“ wird das Ausschalten des PCs so behandelt, als würde er in den Ruhezustand versetzt. Das kann das Hochfahren beschleunigen und den letzten Arbeitsstand erhalten. Weitere Informationen findest du z.B. im [Microsoft Power Management Overview](https://learn.microsoft.com/en-us/windows/win32/power/system-power-states).

Ja, die Hibernate-Methode `persist()` kann Exceptions werfen, die du abfangen (catchen) kannst. Konkret kann `persist()` folgende Exceptions werfen: - **javax.persistence.EntityExistsException**: Wenn die Entität bereits existiert. - **javax.persistence.TransactionRequiredException**: Wenn keine Transaktion aktiv ist. - **javax.persistence.PersistenceException**: Für andere Persistenz-Probleme. Alle diese Exceptions sind **unchecked** (sie erben von `RuntimeException`), das heißt, du bist nicht gezwungen, sie explizit zu catchen, aber du **kannst** sie catchen, wenn du möchtest. Beispiel: ```java try { entityManager.persist(myEntity); } catch (EntityExistsException e) { // Entität existiert bereits } catch (PersistenceException e) { // Allgemeiner Fehler bei der Persistierung } ``` Weitere Infos findest du in der [Hibernate-Dokumentation](https://docs.jboss.org/hibernate/orm/current/javadocs/org/hibernate/Session.html#persist-java.lang.Object-).

Wenn du bei Hibernate die Methode `persist()` aufrufst und dabei ein Fehler (z.B. eine Exception wie `ConstraintViolationException`, `PersistenceException` oder eine andere Laufzeit-Exception) auftritt, und du diesen Fehler **nicht** mit einem `try-catch`-Block abfängst, passiert Folgendes: 1. **Exception propagation:** Die Exception wird an die aufrufende Methode weitergegeben (propagiert). Das bedeutet, dass die aktuelle Methode sofort verlassen wird und die Exception die Call-Stack-Ebenen nach oben wandert, bis sie entweder abgefangen wird oder das Programm beendet. 2. **Transaktionsstatus:** Wenn du dich in einer aktiven Transaktion befindest (z.B. mit JPA oder Hibernate-Transaktionen), wird die Transaktion in der Regel als "markiert zum Rollback" gesetzt. Das heißt, du kannst sie nicht mehr erfolgreich committen, sondern musst sie explizit zurückrollen (`rollback()`). 3. **Session-Status:** Die Hibernate-Session kann in einen inkonsistenten Zustand geraten. Nach einer Exception ist es oft notwendig, die Session zu schließen und eine neue zu öffnen, da sie möglicherweise nicht mehr zuverlässig arbeitet. 4. **Programmabbruch:** Wenn die Exception nicht irgendwann im Call-Stack abgefangen wird, führt das in Java zu einem Programmabbruch mit einer Fehlermeldung (Stacktrace). **Beispiel:** ```java entityManager.persist(myEntity); // Exception wird geworfen // Kein try-catch: Exception propagiert nach oben ``` **Typische Folgen:** - Die aktuelle Transaktion wird abgebrochen. - Nachfolgende Datenbankoperationen schlagen fehl, solange die Transaktion nicht behandelt wurde. - Ohne Fehlerbehandlung kann das gesamte Programm (z.B. ein Servlet, ein Service) abstürzen. **Fazit:** Es ist Best Practice, persistente Operationen wie `persist()` immer in einen `try-catch`-Block zu setzen, um Fehler kontrolliert zu behandeln und die Transaktion sauber zu beenden. Weitere Infos: - [Hibernate Exception Handling](https://docs.jboss.org/hibernate/orm/current/userguide/html_single/Hibernate_User_Guide.html#transactions-exceptions) - [JPA Exception Handling](https://jakarta.ee/specifications/persistence/3.0/jakarta-persistence-spec-3.0.html#exception_handling)

Beim Aufruf der Methode `persist()` in Hibernate können verschiedene Exceptions auftreten. Die wichtigsten sind: 1. **javax.persistence.EntityExistsException** Wird geworfen, wenn versucht wird, eine Entität zu persistieren, die bereits im aktuellen Persistenzkontext existiert. 2. **javax.persistence.TransactionRequiredException** Tritt auf, wenn `persist()` außerhalb einer aktiven Transaktion aufgerufen wird (bei JPA-Implementierungen, die Transaktionen erfordern). 3. **javax.persistence.PersistenceException** Eine generische Exception, die für alle anderen Persistenzprobleme verwendet wird, z.B. bei Datenbankfehlern. 4. **org.hibernate.exception.ConstraintViolationException** Spezifisch für Hibernate: Wird geworfen, wenn ein Datenbank-Constraint verletzt wird (z.B. Unique-Constraint). 5. **org.hibernate.NonUniqueObjectException** Tritt auf, wenn eine andere Instanz mit demselben Identifier bereits im Session-Kontext existiert. 6. **org.hibernate.PersistentObjectException** Wird geworfen, wenn versucht wird, ein bereits persistent gemachtes Objekt erneut zu persistieren. **Hinweis:** Die meisten dieser Exceptions sind Laufzeit-Exceptions (RuntimeExceptions), d.h. sie müssen nicht explizit abgefangen werden, können aber im Fehlerfall auftreten. Weitere Informationen findest du in der [Hibernate-Dokumentation](https://docs.jboss.org/hibernate/orm/current/userguide/html_single/Hibernate_User_Guide.html#persisting-entities-persist). **Zusammenfassung:** - EntityExistsException - TransactionRequiredException - PersistenceException - ConstraintViolationException - NonUniqueObjectException - PersistentObjectException Je nach konkretem Fehlerfall und Datenbank können auch weitere, spezifische Exceptions auftreten.

In Hibernate 6 kannst du den LIKE-Operator für `varchar`-Felder wie gewohnt in JPQL/HQL oder Criteria Queries verwenden. Hier ein Beispiel für beide Varianten: **JPQL/HQL Beispiel:** ```java String pattern = "%suchbegriff%"; List<Entity> result = entityManager.createQuery( "FROM Entity e WHERE e.varcharFeld LIKE :pattern", Entity.class) .setParameter("pattern", pattern) .getResultList(); ``` **Criteria API Beispiel:** ```java CriteriaBuilder cb = entityManager.getCriteriaBuilder(); CriteriaQuery<Entity> cq = cb.createQuery(Entity.class); Root<Entity> root = cq.from(Entity.class); cq.select(root).where(cb.like(root.get("varcharFeld"), pattern)); List<Entity> result = entityManager.createQuery(cq).getResultList(); ``` **Wichtige Hinweise:** - Der LIKE-Operator funktioniert mit allen String-basierten Feldern, also auch mit `varchar`. - Platzhalter: `%` steht für beliebig viele Zeichen, `_` für ein einzelnes Zeichen. - Groß-/Kleinschreibung: Das Verhalten hängt von der Datenbank und deren Kollation ab. Bei Bedarf kannst du `LOWER()` verwenden: ```java WHERE LOWER(e.varcharFeld) LIKE LOWER(:pattern) ``` **Weitere Infos:** - [Hibernate 6 Documentation](https://docs.jboss.org/hibernate/orm/6.0/userguide/html_single/Hibernate_User_Guide.html#hql-like) Falls du spezielle Anforderungen hast (z.B. Escape-Zeichen, native Queries), bitte die Frage präzisieren.

Die Fehlermeldung > org.hibernate.query.SemanticException: Operand of 'like' is of type 'unknown' which is not a string (its JDBC type code is not string-like) bedeutet, dass du im HQL/JPQL-Query oder in einer Criteria-API-Abfrage den `LIKE`-Operator auf eine Spalte oder einen Wert anwendest, der **kein String** ist. Der `LIKE`-Operator funktioniert aber nur mit Zeichenketten (Strings). **Typische Ursachen:** - Du verwendest `LIKE` auf eine numerische, boolesche oder andere nicht-String-Spalte. - Du vergleichst einen Parameter, der als falscher Typ gesetzt wurde (z.B. Integer statt String). - Du hast einen Ausdruck, der zu einem "unknown" Typen evaluiert wird (z.B. durch eine fehlerhafte Cast- oder Coalesce-Nutzung). **Beispiel für einen Fehler:** ```java SELECT e FROM Employee e WHERE e.id LIKE :pattern ``` Hier ist `e.id` vermutlich ein Integer, aber `LIKE` erwartet einen String. **Lösung:** - Stelle sicher, dass beide Seiten des `LIKE`-Operators Strings sind. - Falls du auf eine Nicht-String-Spalte filtern musst, wandle sie explizit um, z.B. mit `CAST()` (sofern von deiner Datenbank unterstützt): ```java SELECT e FROM Employee e WHERE CAST(e.id AS string) LIKE :pattern ``` oder ```java SELECT e FROM Employee e WHERE str(e.id) LIKE :pattern ``` (je nach Datenbank und JPA-Provider) **Parameter richtig setzen:** Wenn du einen Parameter verwendest, stelle sicher, dass du ihn als String setzt: ```java query.setParameter("pattern", "123%"); // nicht als Integer! ``` **Weitere Infos:** - [Hibernate LIKE-Operator Dokumentation](https://docs.jboss.org/hibernate/orm/current/userguide/html_single/Hibernate_User_Guide.html#hql-like) - [JPA CriteriaBuilder LIKE](https://jakarta.ee/specifications/persistence/3.0/jakarta-persistence-spec-3.0.html#criteriaquery-like) **Zusammengefasst:** Der Fehler tritt auf, wenn du `LIKE` auf einen Nicht-String-Typ anwendest. Prüfe und korrigiere den Typ der Spalte und des Parameters, damit beide Strings sind.