MyWackoSite: LayerBadObjectsTransaction ...

Home Page | Каталог | Изменения | НовыеКомментарии | Пользователи | Регистрация | Вход:  Пароль:  
Это старая версия LayerBadObjectsTransaction за 2009-07-06 14:47:36..

Проблема

XWiki может сохранять объекты разных классов в одну строку одной таблицы. Так как RDBR оперирует независимыми объектами, проблемы возникают, когда один объект не может быть сохранен без другого. Это случается, если один из классов отображается не на все столбцы, и среди тех, на которые он не отображается, существуют ненулевые (not nullable). Объект такого класса не удастся сохранить раньше, чем будут заполнены все ненулевые столбцы.

Почему появилась идея

Для реализации проекта возникает необходимость в изменении только библиотеки Hibernate (для отслеживания изменений в БД). XWiki не модифицировалась, и это хорошо. Поэтому для того, чтобы приложение правильно реагировало на нестандартное поведение XWiki, логичнее изменять не сам XWiki (очередной сторонний продукт), а родной Layer.

Идея

Нужно модифицировать Layer так, чтобы каждый приходящий объект проверялся на самодостаточность. Если его нельзя сохранить отдельно от других, то ищем уже существующие дополняющие объекты. Если таких нет, объект не сохраняется в БД, пока не придут дополняющие объекты. Обратное происходит, когда приходит сообщение об удалении дополняющего объекта: он не удаляется, пока не придет сообщение об удалении зависимого.

Реализация

При сохранении зависимого(scanty) объекта проверяем, существуют ли в базе дополняющие(closure) к нему объекты. Если их хватает для сохранения, то все: зависимый и дополняющие – сохраняются в одной транзакции Hibernate в базу данных. Если же остаются незаполненные необходимые столбцы, то объект сохраняется в очередь, его метаинформация не обновляется. При этом считаем, что структуры БД реплицируемых сторон одинаковы. То есть если объект записывается в очередь, то когда-нибудь он из нее удалится, ибо он не может быть создан отдельно от дополняющих. (Проблемы могут возникнуть при реализации частичной репликации!).
С другой стороны, если придет сообщение об удалении экземпляра дополняющего класса, его также придется хранить в очереди, пока не придет сообщение об удалении зависящего от него объекта. (Полагаемся на тот же принцип – в базе данных инициатора дополняющий объект тоже не может быть удален первым).

Обозначения

Очередь – дополнительная таблица, в которой хранятся объекты, которые не могут быть сохранены на данный момент.
Необходимые столбцы для класса – столбцы таблицы с ограничением “not null”, на которые не отображается класс.
Зависимый объект – экземпляр зависимого класса.
Зависимый класс – класс, множество необходимых столбцов которого непусто. Зависимые классы обнаруживаются при анализе маппинга.
Дополняющие к зависимому объекты – которые отображаются в ту же строку, что зависимый и хотя бы на один из необходимых столбцов зависимого класса.

 
Файлов нет. [Показать файлы/форму]
Комментариев нет. [Показать комментарии/форму]