Comment mapper un champ d'entité dont le nom est un mot réservé dans JPA

@Column(name="open")

Utilisation du dialecte sqlserver avec hibernate.

[SchemaUpdate] Unsuccessful: create table auth_session (id numeric(19,0) identity not null, active tinyint null, creation_date datetime not null, last_modified datetime not null, maxidle int null, maxlive int null, open tinyint null, sessionid varchar(255) not null, user_id numeric(19,0) not null, primary key (id), unique (sessionid))
[SchemaUpdate] Incorrect syntax near the keyword 'open'.

Je me serais attendu à ce que hibernate utilise l'identifiant cité lors de la création de la table.

Des idées sur la façon de gérer cela ... autre que de renommer le champ?

Eu le même problème, mais avec un nom de table appelé Transaction. Si vous définissez

hibernate.globally_quoted_identifiers=true

Ensuite, tous les identificateurs de base de données seront cités.

J'ai trouvé ma réponse ici Caractère spécial dans le nom de la table hibernation donnant une erreur

Et trouvé tous les paramètres disponibles ici https://docs.jboss.org/hibernate/orm/5.2/userguide/html_single/appendices/Configurations.html

Impossible de trouver de meilleurs documents pour cela.

Dans mon cas, le paramètre était dans mon fichier de propriétés Spring. Comme mentionné dans les commentaires, il pourrait également être dans d'autres fichiers de configuration liés à la mise en veille prolongée.

Avec Hibernate en tant que fournisseur JPA 1.0, vous pouvez échapper à un mot-clé réservé en l'enfermant dans des backticks:

@Column(name="`open`")

Voici la syntaxe héritée d'Hiberate Core:

5.4. Identificateurs entre guillemets SQL

Vous pouvez forcer Hibernate à citer un identifiant dans le SQL généré en plaçant le nom de la table ou de la colonne entre des crochets inverses dans le document de mappage. Hibernate utilisera le style de citation correct pour le dialecte SQL. Il s'agit généralement de guillemets doubles, mais SQL Server utilise des crochets et MySQL utilise des backticks.

<class name="LineItem" table="`Line Item`">
    <id name="id" column="`Item Id`"/><generator class="assigned"/></id>
    <property name="itemNumber" column="`Item #`"/>
    ...
</class>

En JPA 2.0, la syntaxe est standardisée et devient:

@Column(name="\"open\"")

Références

• Guide de référence Hibernate
  • 5.4. Identificateurs entre guillemets SQL
• Spécification JPA 2.0
  • 2.13 Nommage des objets de base de données

Questions connexes

• Hibernate, MySQL et table nommée «Repeat» - comportement étrange
• Échappement automatique des mots réservés pour les tables et colonnes Hibernate

Échappement manuel des mots-clés réservés

Si vous utilisez JPA, vous pouvez échapper avec des guillemets doubles:

@Column(name = "\"open\"")

Si vous utilisez l'API native Hibernate, vous pouvez les échapper en utilisant des backticks:

@Column(name = "`open`")

Échapper automatiquement les mots-clés réservés

Si vous souhaitez échapper automatiquement aux mots-clés réservés, vous pouvez définir truela hibernate.globally_quoted_identifierspropriété de configuration spécifique à Hibernate :

<property
    name="hibernate.globally_quoted_identifiers"
    value="true"
/>

Format Yaml

spring:
  jpa:
    properties:
      hibernate:
        globally_quoted_identifiers: true

Pour plus de détails, consultez cet article .

Si vous utilisez comme indiqué ci-dessous, cela devrait fonctionner

@Column(name="[order]")
private int order;

@Column(name="\"open\"")

Cela fonctionnera à coup sûr, le même problème s'est produit avec moi lorsque j'apprenais à mettre en veille prolongée.

Non - changez le nom de la colonne.

Ceci est spécifique à la base de données et vous ne pouvez tout simplement pas créer une telle colonne. Après tout, hibernate envoie enfin DDL à la base de données. Si vous ne pouvez pas créer de DDL valide avec ce nom de colonne, cela signifie que la mise en veille prolongée ne le peut pas non plus. Je ne pense pas que les citations résoudraient le problème même si vous écrivez le DDL.

Même si vous réussissez à échapper au nom, changez-le. Cela fonctionnera avec cette base de données, mais ne fonctionnera pas avec une autre.

Certaines implémentations JPA (par exemple celle que j'utilise, DataNucleus) citent automatiquement l'identifiant pour vous, donc vous ne l'obtiendrez jamais.