Isso ocorre porque o comprimento padrão de VARCHAR colunas em instruções DDL criadas pela maioria dos provedores JPA (incluindo Hibernate e EclipseLink) é 255. Especificando o length atributo para o @Column A anotação ajuda a substituir o valor, para que o novo valor seja selecionado pelo gerador de esquema do provedor JPA.

Esta é uma suposição incorreta. O provedor JPA criará tabelas apenas uma vez e não alterará dinamicamente o comprimento da tabela subjacente durante o tempo de vida do aplicativo e somente se você configurar o provedor para criar/atualizar as definições de tabela em primeiro lugar. Além disso, o mapeamento padrão de String é o SQL VARCHAR modelo.

Você parece ter configurado o provedor JPA para criar tabelas conforme necessário (depois de possivelmente eliminá-las), durante o processo de inicialização. Se você estiver usando o Hibernate, isso é feito usando o hibernate.hbm2ddl.auto propriedade especificada em persistence.xml com um valor de update , create ou create-drop . Com EclipseLink, você estaria especificando a propriedade eclipselink.ddl-generation com um valor de create-tables ou drop-and-create-tables .

Ambas as propriedades acima não são recomendadas para uso em uma produção ambiente . A abordagem ideal é ter scripts DDL para criar as tabelas. Já que você está usando VARCHAR , você deve especificar um comprimento adequado na definição da coluna, para ajustar o comprimento máximo da entrada do usuário . Além disso, como você está usando VARCHAR sobre CHAR , o mecanismo de banco de dados garantirá que o espaço de armazenamento alocado dependerá do tamanho dos registros armazenados.

Se você não precisa de uma String para o padrão VARCHAR mapeamento e, em vez disso, usar outro mapeamento válido, você deve usar columnDefinition atributo do @Column anotação. Um exemplo de uso para mapear Calendar para o TIMESTAMPTZ O tipo de dados SQL é mostrado no JPA WikiBook ; você precisará modificá-lo para atender às suas necessidades.