J'ai finalement fait ce "travail" - d'une manière un peu hackeuse - en désactivant la validation de schéma.
Auparavant, j'avais <property name="hibernate.hbm2ddl.auto" value="validate"/>"hibernate.hbm2ddl.auto"
dans mon persistence.xml. Lorsque j'ai commenté cette propriété, mon serveur d'application a démarré et le modèle "a fonctionné".
La forme finale de mon entité était :
@Entity
@Table(schema = "content", name = "theme")
public class Theme extends AbstractBaseEntity {
private static final long serialVersionUID = 1L;
@Column(name = "run_from", columnDefinition = "timestamp with time zone not null")
@NotNull
@Temporal(TemporalType.TIMESTAMP)
private Date runFrom;
@Column(name = "run_to", columnDefinition = "timestampt with time zone not null")
@NotNull
@Temporal(TemporalType.TIMESTAMP)
private Date runTo;
/* Getters, setters, .hashCode(), .equals() etc omitted */
Après avoir lu pas mal de choses à ce sujet, j'ai eu l'impression qu'il n'y a pas de moyen facile de mapper l'horodatage Postgresql avec des colonnes de fuseau horaire.
Certaines combinaisons d'implémentation JPA + base de données le prennent en charge de manière native ( EclipseLink + Oracle en est un exemple ). Pour hibernate, avec les extensions jodatime, il est possible de stocker des horodatages sensibles au fuseau horaire en utilisant un horodatage normal + un champ varchar pour le fuseau horaire (je ne pouvais pas le faire car j'étais contraint de changer le schéma de la base de données). Types d'utilisateurs Jadira ou des types d'utilisateurs entièrement personnalisés peuvent également être utilisés pour résoudre ce problème.
Je dois noter que mon cas d'utilisation pour cette entité est "lecture seule", donc je pourrais m'en tirer avec une "solution" apparemment naïve.