Това е така, защото дължината по подразбиране на VARCHAR колони в DDL изрази, създадени от повечето доставчици на JPA (включително Hibernate и EclipseLink) е 255. Указване на length атрибут към @Column анотацията помага да се отмени стойността, така че новата стойност да бъде уловена от генератора на схеми на доставчика на JPA.
Това е неправилно предположение. Доставчикът на 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 , механизмът на базата данни ще гарантира, че разпределеното място за съхранение ще зависи от размера на записаните записи.
Ако не се нуждаете от низ към VARCHAR по подразбиране съпоставяне и вместо това да използвате друго валидно съпоставяне, тогава трябва да използвате columnDefinition атрибут на @Column анотация. Примерно използване за картографиране на Calendar към TIMESTAMPTZ Типът на SQL данни е показан в JPA WikiBook
; ще трябва да промените това, за да отговаря на вашите нужди.
