Проблема
XWiki может сохранять объекты разных классов в одну строку одной таблицы. Так как RDBR оперирует независимыми объектами, проблемы возникают, когда один объект не может быть сохранен без другого. Это случается, если один из классов отображается не на все столбцы, и среди тех, на которые он не отображается, существуют ненулевые (not nullable). Объект такого класса не удастся сохранить раньше, чем будут заполнены все ненулевые столбцы.
Почему появилась идея
Для реализации проекта возникает необходимость в изменении только библиотеки Hibernate (для отслеживания изменений в БД). XWiki не модифицировалась, и это хорошо. Поэтому для того, чтобы приложение правильно реагировало на нестандартное поведение XWiki, логичнее изменять не сам XWiki (очередной сторонний продукт), а родной Layer.
Идея
Нужно модифицировать Layer так, чтобы каждый приходящий объект проверялся на самодостаточность. Если его нельзя сохранить отдельно от других, то ищем уже существующие дополняющие объекты. Если таких нет, объект не сохраняется в БД, пока не придут дополняющие объекты. Обратное происходит, когда приходит сообщение об удалении дополняющего объекта: он не удаляется, пока не придет сообщение об удалении зависимого.
Реализация
При сохранении зависимого объекта проверяем, существуют ли в базе или очереди дополняющие к нему объекты. Если их хватает для сохранения, то все: зависимый и дополняющие – сохраняются в одной транзакции Hibernate в базу данных и удаляются из очереди (при этом метаинформация обновляется для всех объектов, которые были в очереди). Если же остаются незатронутые необходимые столбцы, то объект сохраняется в очередь, его метаинформация не обновляется. При этом считаем, что структуры БД реплицируемых сторон одинаковы. То есть если объект записывается в очередь, то когда-нибудь он из нее удалится, ибо он не может быть создан отдельно от дополняющих. (Проблемы могут возникнуть при реализации частичной репликации!).
С другой стороны, если придет сообщение об удалении экземпляра дополняющего класса, его также придется хранить в очереди, пока не придет сообщение об удалении зависящего от него объекта. (Полагаемся на тот же принцип – в базе данных инициатора дополняющий объект тоже не может быть удален первым).
Обозначения
Очередь – дополнительная таблица, в которой хранятся объекты, которые не могут быть сохранены на данный момент.
Необходимые столбцы для класса – столбцы таблицы с ограничением “not null”, на которые не отображается класс.
Зависимый объект – экземпляр зависимого класса.
Зависимый класс – класс, множество необходимых столбцов которого непусто. Зависимые классы обнаруживаются при анализе маппинга.
Дополняющие к зависимому объекты – которые отображаются в ту же строку, что зависимый и хотя бы на один из необходимых столбцов зависимого класса.
