2010-07-01 5 views

Répondre

1

Le type MySQL varchar n'est pas sensible à la casse. Ce que vous voulez, c'est varbinary.

CREATE TABLE IF NOT EXISTS `stuff` (
    `id` int(11) UNSIGNED NOT NULL AUTO_INCREMENT, 
    `name` varbinary(255) NOT NULL   -- varbinary to be case sensitive 
) ENGINE=InnoDB DEFAULT CHARSET=utf8; 
+0

Il n'est pas strictement vrai que 'varchar' est insensible à la casse - cela dépend du classement de la table. Par exemple, 'utf8_unicode_cs' est sensible à la casse, alors que' utf8_unicode_cs' ne l'est pas. – Mike

+0

Mais comment JPA peut-il le faire automatiquement lors de la création automatique de schéma? Je ne veux pas manipuler le schéma généré à la main chaque fois que j'utilise mon programme sur un autre ordinateur ou une instance de base de données. – ali

+0

Je ne connais rien à JPA, mais je viens de trouver [Character Encoding UTF-8 avec JPA/Hibernate, MySql et Tomcat] (http://mathiasrichter.blogspot.com/2009/10/character-encoding-utf -8-avec.html). Cela peut être utile. – Mike

7

L'annotation @Column sur votre champ peut spécifier un attribut columnDefinition qui peut vous permettre de spécifier un classement sensible à la casse de la colonne.

public abstract String columnDefinition

        (Facultatif) Le fragment SQL qui est utilisé lors de la génération du DDL pour la colonne.
        Par défaut au SQL généré pour créer une colonne du type inféré.
        Par défaut:
                ""

Dans votre cas, par exemple, en utilisant l'annotation @Column, utilisez

@Column (name = "NAME_COL", columnDefinition = "VARCHAR (250) COLLATE latin1_g eneral_cs ") private Nom de la chaîne;

+0

Ne fonctionne pas malheureusement. Si je fais comme conseillé il semble que JPA a des problèmes en mappant le type de données String à la colonne et lève une exception. – ali

+1

Pouvez-vous fournir l'exception et son message? Quelle implémentation JPA utilisez-vous? – jbindel

Questions connexes