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