JPA - сгенерированный запрос для постоянного метода не вставляет все столбцы - PullRequest
Новая
       26

JPA - сгенерированный запрос для постоянного метода не вставляет все столбцы

0 голосов
/ 12 января 2019

Я довольно новичок в JPA, и у меня возникла проблема с персистентным методом менеджера сущностей для одной конкретной сущности. У меня есть таблица, подобная следующей: 

CREATE TABLE Items
(
  Id                INTEGER                     NOT NULL,
  GroupId           INTEGER                     NOT NULL,
  ItemId            INTEGER                     NOT NULL,
  Expires           NUMBER(9,2)
)

Класс сущности выглядит примерно так: 

@Entity
@Table(name = "Items")
public class Item {
    @Id
    @Column(name = "Id")
    @GeneratedValue(generator = "item_seq", strategy = GenerationType.SEQUENCE)
    @SequenceGenerator(name = "item_seq", sequenceName = "ITEM_SEQ", allocationSize = 1)
    private int id;

    @Column(name = "GroupId")
    private int groupId;

    @Column(name = "ItemId")
    private int itemId;

    @Column(name = "Expires")
    private int expires;

    public int getId() {
        return id;
    }
    public void setId(int id) {
        this.id = id;
    }
    public int getGroupId() {
        return groupId;
    }
    public void setGroupId(int groupId) {
        this.groupId = groupId;
    }
    public int getItemId() {
        return itemId;
    }
    public void setItemId(int itemId) {
        this.itemId = itemId;
    }
    public int getExpires() {
        return expires;
    }
    public void setExpires(int expires) {
        this.expires = expires;
    }
}

В классе репозитория у меня есть следующее: 

@Inject
private UserTransaction userTransaction;
...
userTransaction.begin()
Item item = new Item();
item.setItemId(itemId);
item.setGroupId(groupId);
em.persist(item);
userTransaction.commit()

При попытке зафиксировать следующее исключение:

ORA-01400: невозможно вставить NULL в ("имя-схемы". "Items". "GroupId")

Проблема в том, что JPA генерирует следующий оператор вставки: 

INSERT INTO Items (Id, ItemId) VALUES (?, ?)

Я не могу понять, почему JPA пропускает столбец GroupId. Я подтвердил, что groupId имеет допустимое значение, и я также попытался добавить inserttable = true в атрибут Column. Как я уже говорил, это единственная сущность, где я вижу эту проблему. Я искал вокруг, но не нашел подобных проблем. Я использую Java EE 6, WebSphere и OpenJPA 2.2.3.

1 Ответ

0 голосов
/ 12 января 2019

Эта проблема, скорее всего, связана с тем, что в объявлениях имен и именах таблиц смешаны регистры. Для меня Oracle (около 11,2, если я правильно помню ...) всегда создает все имена таблиц и столбцов UPPERCASE. Ваш сценарий создания может фактически равняться: 

CREATE TABLE ITEMS (
    ID        INTEGER    NOT NULL,
    GROUPID   INTEGER    NOT NULL,
    ITEMID    INTEGER    NOT NULL,
    EXPIRES   NUMBER(9,2)
)

Вы можете форсировать свой собственный случай, заключая имена в " при создании таблиц, например: 

CREATE TABLE "Items" ... -- and all the rest columns

Так что на самом деле вы можете иметь, например, таблицы Items & ITEMS одновременно. (У меня фактически была такая же проблема и с Postgres, который по умолчанию использует все имена в нижнем регистре) .

В любом случае : сначала проверьте, действительно ли ваши поля находятся в базе данных.

Если ваша таблица действительно имеет имена столбцов, такие как GroupId, тогда вы можете попытаться «экранировать» имя в аннотации с помощью ", например: 

@Column(name = "\"GroupId\"")

Если они по умолчанию UPPERCASE, попробуйте соответственно: 

@Column(name = "GROUPID")

Примечание : это должно быть применено ко всем вашим полям с различным регистром.

Особая деталь заключается в том, что - по крайней мере для меня, а также, похоже, имеет место с вами и Oracle - что JPA, тем не менее, находит таблицу независимо от имени, но затем поиск столбцов завершается неудачей.

В большинстве случаев лучшая практика заключается в том, чтобы сохранять вещи по умолчанию, если нет какой-то очень веской причины для отклонений. Поэтому, когда бы мы ни работали с Oracle, мы использовали UPPERCASE везде.

...