org.postgresql.util.PSQLException: 오류: 열 "token"은(는) oid 자료형인데 표현식은 bytea 자료형입니다

잘 되던 스프링 시큐리티가 갑자기 오류가 난다.

 

JPA의 ddl-auto: create로 한번 갈아엎어서 그런가보다 생각이 든다.

token 타입이 잘못됐다고 하니 데이터베이스로 가본다.

생전 처음보는 oid라는 자료형으로 돼 있다...

 

 

검색을 해보니 동일한 오류를 겪은 사람이 있다.

oid 타입은 파일을 파일 시스템에 저장하고 디비에는 주소값 아이디만 저장하는 방식이고

bytea 타입은 바이트 배열을 데이터베이스 내부에 저장하는 방식

oid 방식이 훨씬 효율적이라고 하는데 일단 프로그램이 돌아가야 한다.

여기서는 @Type을 정확하게 지정해줌으로써 해결할 수 있다고 하며 아래 타입을 지정해준다.

    @Type(type="org.hibernate.type.PrimitiveByteArrayBlobType")

PostgreSQL bytea and oid

근데 실제로 해본 결과

해당 타입을 못찾는 문제 발생

버전이 달라져서 클래스 명이 바뀐것 같아 여기저기 검색해보다가 결국

@Type 어노테이션에서 @see에 포함된 Type 인터페이스의 구현체를 참조해서 마땅한것을 찾음

 

구현 목록중에 BinaryType이라는게 있었고

주석을 보면 바이너리 타입으로 데이터베이스에 정의되고 byte[] 코드와 변환된다고 함

이렇게 변경하고 나니까 디비에도 bytea 타입으로 잘 지정이 되고 로그인도 잘 되게 되었다.

근데 알고보니까 이 모든게 @Lob 어노테이션 때문에 발생한 일이었다.

아래 내용처럼 Lob는 사이즈가 크다는 의미를 데이터베이스에 전달하는 어노테이션이었고

나는 두번째 문단 내용처럼 BLOB, CLOB를 쓰고자 하는 경우 @Lob 어노테이션을 쓰라고 하여 사용한 것이었는데

PostgreSQL에서 @Lob를 만나면 따로 blob이라는 자료형이 있지 않고 oid 자료형이 사용되는 것으로 보인다.

결론적으로 @Type을 써줄 필요가 없고 @Lob를 빼버리면 정상 동작한다.

PostgreSQL이 오픈소스 데이터베이스라서 그런지 뭔가 다른점이 많이 보인다.

이번에 보니까 자료형도 정말 다양한 종류가 존재하고...

 

결론은 @Lob를 빼는걸로 났는데 이게 다른 데이터베이스에서 사용해도 같은 결과를 뱉을지가 문제다.

JPA가 데이터베이스 구현체에 영향을 안받으려고 쓰는건데...

연결된 데이터베이스 타입에 따라 옵셔널하게 적용을 해야하나 싶기도 하다.