Как увеличить длину строки в mysql при отображении с помощью JPA

у меня проблемы с JPA. Я был бы очень благодарен, если бы кто-то мог предоставить решение. С JPA (я использую MySQL DB), скажем, у меня есть класс, сопоставленный следующим образом:

@Entity    
class Employee{    
   int id;    
   String employeeName;    
 //getters and setters...   
 }

при сопоставлении с таблицей я вижу, что строка сопоставляется с varchar(255) в Mysql. Однако, скажем, если у меня есть сотрудник, имя которого больше 255 символов, он показывает ошибку усечения данных.

Я знаю, что мы могли бы решить эту проблему, добавив "длина" к Столбец сотрудника как:

@column(length=1000)    
String employeeName;

это единственный возможный способ? Я думал, что если мы просто сопоставим строку в java, база данных будет динамически назначать длину.

2 ответов


при сопоставлении с таблицей я вижу, что строка сопоставляется с varchar (255) в Mysql

это потому, что длина по умолчанию VARCHAR столбцы в инструкциях DDL, созданных большинством поставщиков JPA (включая Hibernate и EclipseLink), равны 255. Указание до @Column аннотация помогает переопределить значение, так что новое значение берется генератором схемы поставщика JPA.

я подумал, если мы просто сопоставьте строку в java, база данных динамически назначит длину.

это неверное предположение. Поставщик JPA будет создавать таблицы только один раз и не будет динамически изменять длину базовой таблицы в течение всего срока службы приложения, и только если вы настроите поставщика для создания/обновления определений таблиц в первую очередь. Кроме того, отображение по умолчанию String является SQL VARCHAR тип.

Вы, кажется, настроил поставщика JPA для создания таблиц по мере необходимости (после возможного их удаления) во время процесса инициализации. Если вы используете Hibernate, это делается с помощью hibernate.hbm2ddl.auto имущество, указанное в persistence.xml стоимостью update, create или create-drop. С помощью EclipseLink вы будете указывать свойство eclipselink.ddl-generation стоимостью create-tables или drop-and-create-tables.

оба вышеуказанных свойства не рекомендуются для использования в производственной среде. Идеал подход состоит в том, чтобы иметь сценарии DDL для создания таблиц. Поскольку вы используете VARCHAR, вы должны указать подходящую длину в определении столбца,чтобы соответствовать максимальной длине пользовательского ввода. Кроме того, поскольку вы используете VARCHAR над CHAR, компонент database engine гарантирует, что выделенное пространство хранения будет зависеть от размера хранимых записей.

Если вам не нужна строка по умолчанию VARCHAR отображение и вместо этого использовать другой допустимый отображение, то вы должны использовать на @Column Примечание. Пример использования для сопоставления Calendar до TIMESTAMPTZ тип данных SQL показан в JPA WikiBook; вам нужно будет изменить это в соответствии с вашими потребностями.


столбцы varchar поддерживают длины динамического размера (без заполнения, как с char), но вы должны указать максимальный размер столбца, если хотите что-то кроме 255. Различные dbs имеют различные ограничения на размер char и varchar (8K или 65k являются общими).

Если вы хотите выйти за этот предел, вам нужно добавить аннотацию @Lob в строку, чтобы она отображалась на тип столбца CLOB (предполагая, что вы позволяете JPA генерировать таблицы). Столбцы CLOB/BLOB могут быть намного больше, чем varchar (снова, точные ограничения зависят от вашей БД). Но у LOBs есть ограничения, такие как не быть первичными ключами или использоваться в предложениях WHERE.