Hibernate @generatedvalue для HSQLDB - PullRequest
Новая
       10

Hibernate @generatedvalue для HSQLDB

9 голосов
/ 30 августа 2010

У меня есть следующее определение для поля id в сущности, сопоставленной с таблицей в HSQLDB. 

...
@Id
@GeneratedValue(strategy=GenerationType.AUTO)
@Column(name = "ID")
private Integer id;
...

Но, похоже, это не создает уникальный идентификатор;вместо этого делается попытка вставить ноль в столбец, что приводит к сбою.Если я вручную создаю последовательность и стратегию генерации, чтобы использовать эту последовательность, то данные сохраняются, как и ожидалось.

Не подразумевает ли стратегия генерации автоматического определения того, что провайдер (в данном случае спящий режим) автоматически выберетправильный подход и выполнять всю тяжелую работу по мере необходимости (создать последовательность, использовать нативный подход или все, что работает для этой конкретной платформы)?Мое понимание неверно?

Ответы [ 2 ]

11 голосов
/ 30 августа 2010

Не подразумевает ли стратегия автоматической генерации, что провайдер (в данном случае в спящем режиме) автоматически выберет правильный подход и выполнит всю тяжелую работу по мере необходимости (создайте последовательность, используйте нативный подход или все, что работает дляэта конкретная платформа)?Мое понимание неверно?

Теоретически (по умолчанию это IDENTITY с HSQLDB), и оно работает для меня.Напрашиваются следующие вопросы:

  • Какой диалект вы используете (на всякий случай)?
  • Как вы создали таблицу?
  • Можете ли вы показать DDL(активировать ведение журнала org.hibernate.tool.hbm2ddl, если требуется)?
  • Как вставить (через API Hibernate, верно?)?

Вот пример DDL для сущности Foo при использовании HSQLDB: 

create table Foo (
    id bigint generated by default as identity (start with 1), 
    bar varchar(100),
    primary key (id)
)

Я создал таблицу, используя менеджер баз данных HSQL.Просто обычный адрес создания таблицы ... В моем случае столбец идентификатора не был задан в качестве идентификатора - просто установите его в качестве первичного ключа.

Тогда у вас есть ответ, используйте столбец IDENTITY.

Хотя Hibernate выбирает правильную стратегию и генерирует соответствующие операторы INSERT (передавая null в идентификатор, который, как ожидается, будет сохранен в столбце IDENTITY), он не будет создавать илиизмените свою физическую модель, если вы не используете возможности генерации и экспорта DDL.

1 голос
/ 15 сентября 2016

У меня возникла та же проблема при использовании служебного класса JpaSchemaGenerator, который я написал.

При создании схемы для org.hibernate.dialect.HSQLDialect (где я использую ПОСЛЕДОВАТЕЛЬНОСТЬ для генерации своих уникальных идентификаторов) я использую следующее свойство Hibernate:

hibernate.id.new_generator_mappings=true

Это приводит к следующему CREATE утверждению: 

CREATE TABLE BATCH (
    BAT_ID NUMBER(19,0) NOT NULL,
    BAT_EXPIRY_DATE TIMESTAMP,
    BAT_NUMBER VARCHAR2(255 CHAR),
    BAT_MAT_ID NUMBER(19,0),
    PRIMARY KEY (BAT_ID)
);

Но когда я использую это же свойство в своем служебном классе для генерации схемы с использованием org.hibernate.dialect.HSQLDialect, я получаю следующий оператор CREATE: 

CREATE TABLE BATCH (
    BAT_ID BIGINT NOT NULL,
    BAT_EXPIRY_DATE TIMESTAMP,
    BAT_NUMBER VARCHAR(255),
    BAT_MAT_ID BIGINT,
    PRIMARY KEY (BAT_ID)
);

Это будет означать, что если бы я создал пакет без идентификатора, он не сгенерировал бы его для меня, и ограничение NOT NULL вызвало бы исключение.

Если я изменю свойство Hibernate на следующее:

hibernate.id.new_generator_mappings=false

Тогда будет сгенерирован следующий оператор CREATE: 

CREATE TABLE BATCH (
    BAT_ID BIGINT GENERATED BY DEFAULT AS IDENTITY (START WITH 1),
    BAT_EXPIRY_DATE TIMESTAMP,
    BAT_NUMBER VARCHAR(255),
    BAT_MAT_ID BIGINT,
    PRIMARY KEY (BAT_ID)
);

Прекрасно работает при создании объектов JPA в Hibernate.

...