JPA2 get column metadata (type, lenth, nullable, etc)

Question

title says it all, I'm working on a JPA2 (through Hibernate 4.0) based data layer that needs to be database agnostic, and I'm trying to retreive whether a column of a table (associated with an @Entity) is nullable, what the type is, and most importantly, if it's a varchar, how long it is.

Answer 1

You can create a database agnostic model, with JPA @Entity's, meaning that your model will work using different DB.

Usually you code your @Entity, an generate the right DDL using SchemaGenerator tool (or other tool) that will create the proper statements for a specific database (using the specified dialect). Your schema is DB agnostic, but at runtime, the proper dialect must be specified.

Be aware that certain key generation mechanism aren't available to some DB and should be avoided to be truly DB agnostic.

Using the @Column annotation on a field, you can define nullable, length etc. If you use the "datatype" property, its becomes your responsibility to use a cross DB type if you want to remain DB agnostic.

There are also other @Temporal & @Enumarated that can influence generated data types.

-- Alternative

You can also map existing table to entities. There are also tools that will do it. By example : http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.jpt.doc.user%2Ftasks021.htm

Be aware to you might have to tweak your mapping / model a bit to be truly database agnostic, as the generated @Entity's mapping may reflect some database specific data types that were used to create the model in the first place.

To my knowledge, generally speaking, JPA is DB agnostic by itself, unless you force datatypes or use unsupported key generation mechanism. It is the right framework to create DB agnostic models.

Even if it may be possible, i don't believe JPA is the right tool to inspect DB types are runtime. So if by "retrieve" you mean inspect and adapt at runtime... you might be better of using straight JDBC. If you need to inspect DB at runtime and react accordingly, it is the opposite of DB agnostic code, you treat all possible cases.