Develop Reference

Hibernate #Lob on byte[] causes "Bad value for type long"

I'm trying to lazily fetch single byte[] content java property using Hibernate under Spring Boot, accessing PostgreSQL database. So I pulled together testing app for testing different solutions. One of them required me to use #Lob annotation on said property, so I did. Now reading entity from the database leads to very curious error, precisely:
Bad value for type long : \x454545454545445455
The value \x45... is value of bytea column not the bigint one, why is it trying to force it into the long even though it's wrong column? Why annotation on one column somehow affects another one?
As for fix, removing #Lob seems to work (at least in my stack) but the problem remains unexplained to me and I would like to know what is going rather than just blindly moving on. Is it bug or I am misunderstanding something completely?
Entity:
#Entity
#Table(name = "blobentity")
public class BlobEntity {
#Id
#GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
#Lob //this annotation breaks code
#Column(name = "content")
#Basic(fetch = FetchType.LAZY)
private byte[] content;
#Column(name = "name")
private String name;
//getters/setters
}
Repository:
#Repository
public interface BlobRepo extends JpaRepository<BlobEntity, Long> {
}
Calling code:
#Autowired
BlobRepo blobrepo;
#GetMapping("lazyBlob")
public String blob () {
var t = blobrepo.findAll().get(0);
var name = t.getName();
var dataAccessedIfLazy = t.getContent();
return t.getName();
}
Postgres DDL:
CREATE TABLE test.blobentity (
id bigserial NOT NULL DEFAULT nextval('test.blobentity_id_seq'::regclass),
"name" varchar NULL,
"content" bytea NULL,
CONSTRAINT blobentity_pk PRIMARY KEY (id)
);
Select result:
Used version:
PostgreSQL 10.4; springframework.boot 2.4.2; hibernate version that comes with this spring boot version

The bytea type is inlined into the table whereas other types are chunked into a separate table which is called TOAST on PostgreSQL. To access these values, database have a concept often referred to as a LOB locator which essentially is just an id for doing the lookup. Some drivers/databases just work either way but others might need to match the actual physical representation. In your case, using #Lob is just wrong because AFAIK bytea is inlined up to a certain size and de-TOASTed i.e. materialized automatically behind the scenes if necessary. If you were using the varbinary/blob type or something like that, you would have to use #Lob as in that case, the main table only contains this LOB locator which is a long. The driver then knows when you ask for the value by using getBlob that it has to execute some select get_lob(?) query to retrieve the actual contents.

Alter table from jpa annotations in Java

I have a definition for a column like that:
#Column
private String my_column;
And by default in Postgres database type for this field is character varying(255).
Now, I want to change the data type for this column.
How I can do this without entry in database and alter table?
I tried this:
#Lob
#Column
private String my_column;
And
#Column(columnDefinition = "TEXT")
private String my_column;
But, without results.

The thing is, that JPA does not handle Schema changes.
JPA maps your existing DB to Java Classes, it does not manage the database it self.
As for schema changes managment.
A common practice is to have a schema migration tool to handle that, for example Flyway and Liquibase are a popular solutions.
There you can write a SQL script, to change the DB column type to "text"
and it will apply those changes when you run the DB migration process.
Or you can always just access your DB and modify it manually.

Longblob alternative in Hibernate + HSQLDB

I have a column in a MySQL database defined as LONGBLOB. This is the java code used on its mapping:
#Type(type = "org.hibernate.spatial.GeometryType")
#Column(columnDefinition = "LONGBLOB")
private Point latlng;
I want now to share this definition in an HSQLDB (for in-memory testing), but unfortunately HSQLDB doesn't have the LONGBLOB type.
I know about the HSQLDB alternatives such as LONGVARBINARY, but how I can instruct Hibernate to use LONGBLOB on MySQL and LONGVARBINARY on HSQLDB?
(I can't replace the #Column with #Lob; I tried that and Hibernate uses by default a "geometry" type instead of "longblob". Changing the current MySQL mapping is not an option.)

XML mappings with orm.xml overwrites annotated mappings.
So, you could include XML mapping file for this entity in /src/test/resources/ and define the proper datatype for this column.

saving Oracle XMLType type column using JPA

I have a column type defined in Oracle as XMLTYPE and I am trying to save xml content using JPA. I have used something like in my entity class.
#CLOB
#Column(name = "COLOUM_NAME")
private String coloumName;
But i am getting the following exception.
ORA-01461: can bind a LONG value only for insert into a LONG column
Any solution for above issue?

You don't need #CLOB annotation here. Just use String type.

How to Tell JPA the prefered DataType

If I use JPA (EclipseLink) to create tables a String type results in a varchar2(255). How could I tell JPA (via Annotation) to create a varchar2(20) attribute.
If I have a List JPA creates a BLOB(4000) but I would like a varchar2 (my serialized object's string is short)
How is this possible? Do I have to do it by hand?

You need to use the columnDefinition property of the #Column annotation. i.e.
#Column(columnDefinition="varchar2(20)")

If I use JPA (EclipseLink) to create tables a String type results in a varchar2(255). How could I tell JPA (via Annotation) to create a varchar2(20) attribute.
Using the columnDefinition can break portability from one database to another. For a string-valued column, prefer using the length element (which defaults to 255):
#Column(length=20)
String someString;

You can set the length on your #Column annotation, as such:
#Column(length = 20)
Note that length is only for text columns. For numeric, you can use precision and scale.

#Column(name = "doc_number", columnDefinition = "varchar2(20)")
Please, try that.