2016-04-25 37 views
2

Nach dem Wechsel von MySQL zu PostgreSQL Ich habe herausgefunden, dass meine SQL-Abfrage (@Query im Frühjahr Daten Repository-Schnittstelle) nicht mehr funktioniert. Das Problem wird durch null Wert verursacht als bytea gesendet werden und ich bin immer folgende Ausnahme:Spring Data Repository sendet null als Bytea an PostgreSQL-Datenbank

Caused by: org.postgresql.util.PSQLException: ERROR: operator does not exist: bigint = bytea 
Hint: No operator matches the given name and argument type(s). You might need to add explicit type casts. 

Repository mit @Query:

public interface WineRepository extends PagingAndSortingRepository<Wine, Long> { 
    @Query(value = "SELECT * FROM WINE w WHERE (?1 IS NULL OR w.id = ?1)", nativeQuery = true) 
    Wine simpleTest(Long id); 
} 

Einfacher Test:

LOGGER.warn("test1: {}", wineRepository.simpleTest(1L)); //ok 
LOGGER.warn("test2: {}", wineRepository.simpleTest(null)); //PSQLException 

Im wirklichen Fall habe ich mehrere Parameter, die null sein können und ich würde es vorziehen, sie nicht in Java-Code zu überprüfen aber sende sie an sql query. Ich habe Fragen hier auf Stackoverflow überprüft, aber keine mit einer guten Antwort speziell für Frühjahr Daten Repository @query Annotation gefunden.

Was ist eine korrekte Methode zur Behandlung von Nullwerten mit PostgreSQL? Oder haben Sie Hinweise, wie Sie meinen Ansatz korrigieren können? Danke!

Update: Ausgabe scheint nativeQuery = true verwandt zu sein, wenn der Wert falsch ist, Nullwerte wie erwartet. Die Frage ist also, ob es möglich ist, dass es auch mit nativeQuery funktioniert.

Antwort

0

Sie versuchen zu überprüfen, ob ein Java null gleich Postgres NULL ist, die ich denke, ist nicht notwendig. Sie können wie folgt umschreiben und vermeiden, null an die simpleTest-Funktion zu senden.

+1

Aber meine Absicht ist zu überprüfen, ob die Eingabe von Java null ist. Ich versuche nicht, Werte aus der Datenbank auszuwählen, die null sind. – rhorvath

0

Ich hatte ein ähnliches Problem in einer @Query, wo ein Long von Postgres als Bytea interpretiert wurde. Die Lösung für mich war, das @Param zu entpacken, indem ich einen langen Wert übergebe, interpretierte Postgres den Wert korrekt als Bigint.

Verwandte Themen