Właściwie używałem prostszego sposobu niż ten z PGObject i konwerterami. Ponieważ w Postgresie wyliczenia są konwertowane dość naturalnie na tekst, po prostu pozwól mu robić to, co robi najlepiej. Pożyczę przykład nastrojów Arjana, jeśli mu to nie przeszkadza:
Typ wyliczenia w Postgresie:
CREATE TYPE mood AS ENUM ('sad', 'ok', 'happy');
Klasa i wyliczenie w Javie:
public @Entity class Person {
public static enum Mood {sad, ok, happy};
@Enumerated(EnumType.STRING)
Mood mood;
}
Ten tag @Enumerated mówi, że serializacja/deserializacja wyliczenia powinna być wykonywana w tekście. Bez niego używa int, co jest bardziej kłopotliwe niż cokolwiek innego.
W tym momencie masz dwie opcje. Ty albo:
-
Dodaj stringtype=nieokreślony do ciągu połączenia, jak wyjaśniono w parametrach połączenia JDBC. Pozwala to Postgresowi odgadnąć typ po prawej stronie i odpowiednio przekonwertować wszystko, ponieważ otrzymuje coś w rodzaju „enum =nieznane”, czyli wyrażenie, z którym już wie, co zrobić (feed wartość ? do deserializatora po lewej stronie). To jest preferowana opcja, ponieważ powinno działać dla wszystkich prostych UDT, takich jak wyliczenia za jednym razem.
jdbc:postgresql://localhost:5432/dbname?stringtype=unspecified
Lub:
-
Utwórz niejawną konwersję z varchar na enum w bazie danych. Tak więc w tym drugim przypadku baza danych otrzymuje pewne przypisanie lub porównanie, takie jak „enum =varchar” i znajduje regułę w swoim katalogu wewnętrznym, mówiącą, że może przekazać wartość po prawej stronie przez funkcję serializacji varchar, po której następuje funkcja deserializacji wyliczenie. To więcej kroków niż powinno być; a posiadanie zbyt wielu niejawnych rzutowań w katalogu może spowodować, że dowolne zapytania będą miały niejednoznaczne interpretacje, więc używaj go oszczędnie. Kreacja obsady to:
TWÓRZ OBSŁUGĘ (CHARAKTER RÓŻNIĄCY SIĘ JAKO NATRYB) Z INOUT JAKO IMPLICY;
Powinno działać właśnie z tym.
