Detta beror på att standardlängden för VARCHAR kolumner i DDL-satser skapade av de flesta JPA-leverantörer (inklusive Hibernate och EclipseLink) är 255. Ange length attribut till @Column annotering hjälper till att åsidosätta värdet så att det nya värdet plockas upp av JPA-leverantörens schemagenerator.
Detta är ett felaktigt antagande. JPA-leverantören kommer bara att skapa tabeller en gång och kommer inte dynamiskt att ändra längden på den underliggande tabellen under applikationens livstid, och endast om du konfigurerar leverantören att skapa/uppdatera tabelldefinitionerna i första hand. Dessutom är standardmappningen av String är SQL VARCHAR typ.
Du verkar ha konfigurerat JPA-leverantören för att skapa tabeller efter behov (efter att ha släppt dem) under initieringsprocessen. Om du använder Hibernate görs detta med hibernate.hbm2ddl.auto egenskap specificerad i persistence.xml med värdet update , create eller create-drop . Med EclipseLink skulle du ange egenskapen eclipselink.ddl-generation med värdet create-tables eller drop-and-create-tables .
Båda ovanstående egenskaper rekommenderas inte för användning i en produktion miljö
. Det ideala tillvägagångssättet är att ha DDL-skript för att skapa tabellerna. Eftersom du använder VARCHAR , bör du ange en lämplig längd i kolumndefinitionen, för att passa den maximala längden på användarinmatningen . Dessutom, eftersom du använder VARCHAR över CHAR , kommer databasmotorn att säkerställa att det tilldelade lagringsutrymmet beror på storleken på de poster som lagras.
Om du inte behöver en sträng till standard VARCHAR mappning och istället använda en annan giltig mappning, då måste du använda columnDefinition attribut för @Column anteckning. Ett exempel på användning för att kartlägga Calendar till TIMESTAMPTZ SQL-datatypen visas i JPA WikiBook
; du måste ändra detta för att passa dina behov.