Форматы файлов настроек
Описание зависимости объектов
Предлагаю предоставить полную свободу описаний зависимостей. По каждому объекту, используя загрузчик, можно получить его замыкание. Набросок схемы файла:
<one-sided name=string
atSameTransaction=boolean
onDelete=(“noOrder”| “reverseOrder”| “deleteAll”) [atWrongOrder=(“ignore”| “save”| “wait”)] > – описание односторонней зависимости объектов
<dependentEntity>string</dependentEntity> – описание класса зависимого объекта
<loaderAlias>string</loaderAlias>
<parameter name=string>string</parameter> – параметры метода
...
<parameter name=string>string</parameter>
</one-sided>
<many-sided name=string
atSameTransaction=boolean
> – описание неразделимого множества объектов
<entity>string</entity> – описания классов объектов группы
...
<entity>string</entity>
<loaderAlias>string</loaderAlias>
<parameter name=string>string</parameter> – параметры метода
...
<parameter name=string>string</parameter>
</many-sided>
<loader>
<loaderClassName>string</loaderClassName>
<methodName>string</methodName>
<alias>string</alias>
</loader>
Метод загрузчика должен иметь вид:
Map<_dependentClass_, Set<_closureClass_>> LoaderName.methodName( Set<_dependentClass_> obj, Properties parameters);
Пусть зависимость определена с аттрибутом
atSameTransaction="true". Тогда информация о ней передается при репликации зависимого объекта. Если это множество(many-sided) – порядок не важен, если дерево из односторонних зависимостей – важен. (Если ОЗ образуют цикл – это ошибка).
Пусть теперь зависимость определена с аттрибутом
atSameTransaction="false". Тогда дерево ОЗ влияет на очередь отправки объектов (получившееся дерево объектов является одной группой отправки), информация о зависимостях не передается. Множество в этом случае не имеет особого смысла, но его тоже можно обрабатывать как одну группу отправки.
Описание решений конфликтов
Можно описать правила выбора объекта при конфликте: например, что один узел «авторитетнее» другого, узел более или менее «авторитетный», чем остальные; то же самое для отдельных классов. Также можно позволить добавить имя класса с методами, выбирающими между двумя объектами фиксированного (или любого) класса.
Для каждого правила определить приоритет.
Тогда при конфликте обязанность выбора падет на администратора только если:
- нет правила выбора между двумя объектами
- правила с одинаковым и наибольшим (среди всех правил, по которым можно разрешить этот конфликт) приоритетом требуют разного поведения.
(Основано на слухах, что скоро конфликты можно будет разрешать «руками», через панель администрирования репликатора).
