Изучаем Java EE 7

··private String nickname;

··private String content;

··private Integer note;

··// Конструкторы, геттеры, сеттеры

}

Для сохранения сортировки без даты размещения в случае с сущностью News (показанной в листинге 5.53) можно аннотировать связь с помощью @OrderColumn. Тогда поставщик постоянства отобразит сущность News в таблицу с дополнительным столбцом для сохранения сортировки.

Листинг 5.53. Обеспечение постоянства сортировки комментариев

@Entity

public class News {

··@Id @GeneratedValue

··private Long id;

··@Column(nullable = false)

··private String content;

··@OneToMany(fetch = FetchType.EAGER)

··@OrderColumn(name = "posted_index")

··private List comments;

··// Конструкторы, геттеры, сеттеры

}

В листинге 5.53 @OrderColumn переименовывает дополнительный столбец в POSTED_INDEX. Если это имя не будет изменено, то по умолчанию имя столбца будет представлять собой конкатенацию имени атрибута сущности и строки _ORDER (COMMENTS_ORDER в нашем примере). Этот столбец должен иметь числовой тип. Соответствующая упорядоченная связь будет отображена в отдельную таблицу соединения, как показано далее:

create table NEWS_COMMENT (

····NEWS_ID BIGINT not null,

····COMMENTS_ID BIGINT not null,

····POSTED_INDEX INTEGER

);

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

Переносимым приложениям не следует ожидать, что список будет упорядочен базой данных, предполагая, что движки некоторых баз данных автоматически оптимизируют их индексы, благодаря чему таблица данных выглядит отсортированной. Вместо этого для них следует использовать конструкцию @OrderColumn либо @OrderBy. Нужно отметить, что вы не сможете одновременно задействовать обе эти аннотации.

Отображение наследования

Объектно-ориентированные языки задействуют парадигму наследования с момента своего появления. C++ допускает множественное наследование, а Java поддерживает наследование от одного класса. Применяя объектно-ориентированные языки, разработчики обычно повторно используют код, наследуя атрибуты и поведения корневых классов.

Вы только что изучили связи, а связи между сущностями очень просто отображаются в реляционную базу данных. Однако с наследованием дело обстоит по-другому. В реляционном мире наследование — неизвестная концепция, которая изначально не реализована там. Концепция наследования предполагает использование ряда трюков при сохранении объектов в реляционную базу данных.

Как превратить иерархическую модель в плоскую реляционную модель? JPA предлагает на выбор три разные стратегии.

• Иерархическая стратегия «одна таблица на класс» — совокупность атрибутов всей иерархии сущностей отображается в одну таблицу (применяется по умолчанию).

• Стратегия «соединенный подкласс» — при этом подходе каждая сущность в иерархии, конкретная или абстрактная, отображается в свою специально отведенную для этого таблицу.

• Стратегия «таблица на конкретный класс» — при использовании этой стратегии каждая иерархия конкретных сущностей отображается в свою отдельную таблицу.

Примечание

Поддержка стратегии отображения «таблица на конкретный класс» в версии JPA 2.1 все еще необязательна. Лучше не применять ее для переносимых приложений до тех пор, пока ее поддержка не станет обязательной официально.