Как увеличить длину строки в 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.