Изучаем Java EE 7 - [78]

Листинг 5.51. Комментарии, которые относятся к сущности News, упорядочиваются согласно дате размещения в убывающем порядке

@Entity
public class News {
··@Id @GeneratedValue
··private Long id;
··@Column(nullable = false)
··private String content;
··@OneToMany(fetch = FetchType.EAGER)
··@OrderBy("postedDate DESC")
··private List comments;
··// Конструкторы, геттеры, сеттеры
}

Аннотация @OrderBy принимает имена атрибутов, которые должны быть отсортированы (атрибут postedDate), а также метод (сортировка в возрастающем или убывающем порядке). Строка ASC или DESC может быть использована для обеспечения сортировки соответственно либо в возрастающем, либо в убывающем порядке. Аннотация @OrderBy может охватывать несколько столбцов. Если вам потребуется выполнить упорядочение согласно дате размещения и примечаниям, то вы сможете воспользоваться OrderBy("postedDate DESC, note ASC").

Аннотация @OrderBy никак не влияет на отображение базы данных. Поставщик постоянства просто информируется о необходимости использовать предложение ORDER BY при извлечении коллекции во время выполнения.

@OrderColumn

Версия JPA 1.0 позволяла осуществлять динамическое упорядочение с использованием аннотации @OrderBy, однако не предусматривала возможности поддерживать постоянное упорядочение. С выходом JPA 2.0 это стало возможным благодаря добавлению аннотации @OrderColumn (ее API-интерфейс схож с API-интерфейсом аннотации @Column из листинга 5.12). Эта аннотация информирует поставщика постоянства о том, что он должен обеспечить поддержку упорядоченного списка с использованием отдельного столбца, в котором располагается индекс. @OrderColumn определяет этот отдельный столбец.

Воспользуемся примером сущностей News и Comment и немного изменим его. На этот раз у сущности Comment, показанной в листинге 5.52, не будет атрибута postedDate и, следовательно, сортировка комментариев в хронологическом порядке окажется невозможной.

Листинг 5.52. Сущность Comment без postedDate

@Entity
public class Comment {
··@Id @GeneratedValue
··private Long id;
··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 предлагает на выбор три разные стратегии.

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