Форматы файлов настроек
Описание зависимости объектов
Предлагаю предоставить полную свободу описаний зависимостей. По каждому объекту, используя загрузчик, можно получить его замыкание. Набросок схемы файла:
<dependency name=string
atSameTransaction=boolean
onDelete=(“noOrder”| “reverseOrder”| “deleteAll”) [atWrongOrder=(“ignore”| “save”| “wait”)] > – описание односторонней зависимости объектов
<dependentEntity name=string /> – описание класса зависимого объекта
<closureEntity name=string /> – описание класса объекта-замыкания
<closureEntityLoader>string</closureEntityLoader> – имя класса-загрузчика для замыкания
</dependency>
<set name=string
atSameTransaction=boolean
> – описание множества объектов
<entity name=string /> – описания классов объектов группы
...
<entity name=string />
<loader>string</loader> – имя класса – загрузчика множества по объекту
</set>
Имя множества или односторонней зависимости может использоваться для построения названия метода, по которому загружаются объекты-замыкания. Например:
{closureClass} Loader.get For Dependency?{dependencyName} ( {dependentClass} obj );
Set<{dependentClass}> Loader.get For Set?{setName} ( {dependentClass} obj );
Пусть зависимость определена с аттрибутом
atSameTransaction="true". Тогда информация о ней передается при репликации зависимого объекта. Если это множество – порядок не важен, если дерево из односторонних зависимостей – важен. (Если ОЗ образуют цикл – это ошибка).
Пусть теперь зависимость определена с аттрибутом
atSameTransaction="false". Тогда дерево ОЗ влияет на очередь отправки объектов (получившееся дерево объектов является одной группой отправки), информация о зависимостях не передается. Множество в этом случае не имеет особого смысла, но его тоже можно обрабатывать как одну группу отправки.
Описание решений конфликтов
Можно описать правила выбора объекта при конфликте: например, что один узел «авторитетнее» другого, узел более или менее «авторитетный», чем остальные; то же самое для отдельных классов. Также можно позволить добавить имя класса с методами, выбирающими между двумя объектами фиксированного (или любого) класса.
Для каждого правила определить приоритет.
Тогда при конфликте обязанность выбора падет на администратора только если:
- нет правила выбора между двумя объектами
- правила с одинаковым и наибольшим (среди всех правил, по которым можно разрешить этот конфликт) приоритетом требуют разного поведения.
(Основано на слухах, что скоро конфликты можно будет разрешать «руками», через панель администрирования репликатора).
