Самые типичные данные
Разница между XML-данными и XML-запросами
Браузер по HTTP-протоколу может отправлять xml-данные,
которые нужно запомнить - он отправляет их из формы,
а может отправлять сами запросы, записанные в xml-виде -
он отправляет их из
авто-таблицы
и из
авто-дерева.
СУБД получает по HTTP-протоколу и то, и другое,
но xml-данные нужно направить в один двигатель, а xml-запросы - в другой.
Для того, чтобы такое разграничение было возможным,
xml-послания различаются корневым сегом:
у XML-данных он
formdata,
а у XML-запросов он
tabledata
(для авто-таблицы) или
treedata
(для авто-дерева).
Xml-данные вызывают триггер,
повешенный на операцию 'insert' в таблицу 'formdata',
который написан на смеси DML и TML,
а xml-запросы выполняются непосредственно,
если они соответствуют стандарту
MTD (most typical data - самые типичные данные):
- сеги
_
и file
должны иметь установленный формат
- все остальные сеги должны содержать столько
серибутов,
сколько полей в одноименной таблице (или view-шке),
и названия серибутов должны совпадать с названиями полей
Перед выполнением запроса его содержимое
(т.е. tabledata
и его под-деревья,
treedata
и его под-деревья)
записываются в базу данных точно также,
как это делается для formdata
.
Имя пользователя и пароль для базы данных запрашиваются по HTTP.
Выполненные в базе данных MTD автоматически commit-ся.
Отключение MTD
Чтобы отключить реакцию MTD на tabledata
,
достаточно повесить триггер на операцию 'insert' в таблицу 'tabledata'
(триггер может быть написан на смеси DML и TML).
create trigger TriggerName for tabledata
after insert as begin
-- empty trigger
end;;
Чтобы отключить реакцию MTD на treedata
,
достаточно повесить триггер на операцию 'insert' в таблицу 'treedata'
(триггер может быть написан на смеси DML и TML).
create trigger TriggerName for treedata
after insert as begin
-- empty trigger
end;;
Порядок сортировки для MTD
Записи таблицы сортируются по всем существующим для нее индексам.
Ширина индекса - количество используемых в нем колонок таблицы.
Близость индекса - количество перестановок,
которыми порядок следования колонок в индексе может быть приведен
к порядку следования колонок в таблице.
Сортировка производится:
- сначала по более широкому индексу, потом по более узкому
- среди индексов равной ширины
сначала по более близкому индексу, потом по более дальнему
- сортировка по индексу не выполняется совсем,
если хотя бы одна из его колонок уже была задействована для сортировки
по более широкому или более близкому индексу
Виды запросов
Tabledata
Одиночная таблица
Запрос
браузера
<tabledata>
<_ name="A" event="TableDown" arg="50">
</tabledata>
означает требование выслать первые 50
доступных для данного пользователя
записей таблицы (или view-шки), которая имеет название 'A'
(имя и пароль пользователя передаются по HTTP).
СУБД высылает записи в виде сегов,
имена которых совпадают с названием таблицы (view-шки),
и имена серибутов которых
совпадают с названиями полей таблицы (view-шки).
<a a1="v1_1" a2="v1_2" a3="v1_3" >
<a a1="v2_1" a2="v2_2" a3="v2_3" >
...
<a a1="v50_1" a2="v50_2" a3="v50_3">
Одновременно с данными
браузер
может запрашивать количество записей в таблице запросом
<tabledata>
<_ name="A" event="TableDown" arg="50">
<_ name="A" event="count">
</tabledata>
в ответ на что сервер присылает
<a a1="v1_1" a2="v1_2" a3="v1_3" >
<a a1="v2_1" a2="v2_2" a3="v2_3" >
...
<a a1="v50_1" a2="v50_2" a3="v50_3">
<_ name="A" event="count" arg="10 000">
Запросы
<tabledata>
<_ name="A" event="TableDown" arg="50">
<a a1="v1_50" a2="v2_50" a3="v3_50">
</tabledata>
и
<tabledata>
<_ name="A" event="TableUp" arg="50">
<a a1="v1_51" a2="v2_51" a3="v3_51">
</tabledata>
означают соответственно требования выслать 50 записей
после или перед указанной записи.
Запрос
<tabledata>
<_ name="A" event="TableDelete">
<a a1="v1_2" a2="v2_2" a3="v3_2">
</tabledata>
означает требование удалить указанную запись,
в ответ на что сервер присылает
или
А запрос
(если значение name
сега file
содержит название серибута, например a3,
и кроме того, значение filename
сега file
равно значению серибута a3
,
то сервер считает, что упомянутый файл и есть содержимое серибута)
<tabledata>
<_ name="A" event="TableInsert">
<a a1="v1_new" a2="v2_new" a3="tiger.jpg">
<file name="a3" filename="tiger.jpg">Y29udGVudHMgb2YgZmlsZTEudHh0</file>
</tabledata>
означает требование вставить указанную запись,
в ответ на что сервер присылает
или
Запрос
<tabledata>
<_ name="A" event="TableUpdate">
<a a1="v1_3" a2="v2_3" a3="v3_3">
<a a1="v1_changed" a2="v2_3" a3="tiger.jpg">
<file name="a3" filename="tiger.jpg">Y29udGVudHMgb2YgZmlsZTEudHh0</file>
</tabledata>
означает требование заменить первую из указанных записей
(она должна содержаться в базе данных) на вторую,
сервер присылает
или
Отношение "главнЫЕ-подчиненная" между таблицами
Запрос
<tabledata>
<_ name="S" event="TableDown" arg="40">
<m m1="v15_1" m2="v15_2" m3="v15_3">
<n n1="v23_1" n2="v23_2" n3="v23_3">
<p p1="v47_1" p2="v47_2" p3="v47_3">
</tabledata>
означает, что
- таблица 'S' ссылается внешними ключами (foreign keys) на таблицы 'M, N, P';
и от СУБД требуется проанализировать системную информацию и найти,
какими полями ссылается таблица 'S' и на какие поля таблиц 'M, N, P'
(если хотя бы одна из таблиц 'M, N, P' не имеет упомянутой связи,
то запрос является неудачным)
- на основании полученных записей таблиц 'M, N, P'
требуется найти (первую) запись таблицы 'S'
- требуется прислать найденную и 39 последующих записей таблицы 'S'
Сервер отвечает обычным способом
<s s1="v1_1" s2="v1_2" s3="v1_3" >
...
<s s1="v40_1" s2="v40_2" s3="v40_3">
Специальный запрос к одиночной таблице
Запрос
<tabledata>
<_ name="B" event="SelectDown" arg="40">
</tabledata>
означает то же самое, что и запрос
<tabledata>
<_ name="B" event="TableDown" arg="40">
</tabledata>
но ответ должен быть выслан специальным образом
- СУБД должна проанализировать системную информацию и найти,
какое поле является первичным ключом
(если несколько полей входит в первичный ключ,
то запрос является неудачным)
- значение первичного ключа должно быть выслано не в серибуте, одноименном полю,
а в серибуте
value
- значения всех полей, не входящим в первичный ключ,
должны быть взяты в порядке следования полей в таблице
и склеины в через пробел в одну строку
- полученная строка должна быть выслана как содержимое элединга
option
<option value="subs1" >word1 <option>
<option value="subs2" >word2 <option>
<option value="subs3" >word3 <option>
...
<option value="subs40">word40<option>
Одновременно с данными
браузер
может запрашивать количество записей в таблице
запросом
<tabledata>
<_ name="B" event="SelectDown" arg="40">
<_ name="B" event="count">
</tabledata>
в ответ на что сервер присылает
<option value="subs1" >word1 <option>
<option value="subs2" >word2 <option>
<option value="subs3" >word3 <option>
...
<option value="subs40">word40<option>
<_ name="B" event="count" arg="100">
Запросы
<tabledata>
<_ name="B" event="SelectDown" arg="40">
<option id="id40" value="subs40">word40<option>
</tabledata>
и
<tabledata>
<_ name="B" event="SelectUp" arg="40">
<option id="id41" value="subs41">word41<option>
</tabledata>
означают соответственно требования выслать 40 записей после или до
указанной записи.
Запрос
<tabledata>
<_ name="B" event="SelectDownRough" arg="40" arg2="word">
</tabledata>
требует
- найти записи,
склеенная строка из не-первичных полей которых
имеет отличие не более 2 от значения,
указанное в серибуте
arg2
- выслать первые 40 найденных записей
А запросы
<tabledata>
<_ name="B" event="SelectDownRough" arg="40" arg2="word">
<option value="subs40">word40<option>
</tabledata>
и
<tabledata>
<_ name="B" event="SelectUpRough" arg="40" arg2="word">
<option value="subs40">word40<option>
</tabledata>
означают соответственно
требования выслать 40 "приблизительно равных" записей,
расположенных после или до указанной "приблизительно равной" записи.
Treedata
Запрос
браузера
<treedata>
<_ name="A" event="TreeClick" arg="2">
</treedata>
означает, что
- таблица 'A' ссылается на саму себе только одним внешним ключом
(если таких внешних ключей несколько,
то запрос является неудачным)
- СУБД должна проанализировать системную информацию и найти,
каким полем (например, 'fk') и на какое поле (например, 'pk')
ссылается таблица 'A'
- требуется найти (первую) запись таблицы 'A',
в которой поле 'pk' равно "4"
- по найденной записи
требуется найти и выслать все записи, которые на нее ссылаются -
причем не в сегах, одноименных таблице,
а в сегах
li
- значение поля 'pk' должно быть выслано не в серибуте, одноименном полю,
а в серибуте
id
- значения всех полей, кроме 'pk' и 'fk',
должны быть взяты в порядке следования полей в таблице
и склеины в через пробел в одну строку
- полученная строка должна быть выслана как содержимое элединга
li
- в каждом высылаемом
li
нужно указать серибут
filled
=yes,
если существуют записи, ссылающиеся на отправляемую запись
Таким образом сервер отвечает
<li id=3 > folder_name3 </li>
<li id=4 filled=yes> folder_name4 </li>
Запросы
<treedata>
<_ name="A" event="TreeDrag" arg="3">
<_ name="A" event="TreeDrop" arg="5">
</treedata>
и
<treedata>
<_ name="A" event="TreeCopy" arg="3">
<_ name="A" event="TreeDrop" arg="5">
</treedata>
означают, что соответственно
требование присвоить полю 'fk' записи, у которой поле 'pk'=3, значение "5" и
требование скопировать запись, у которой поле 'pk'=3, и присвоить 'fk'=5 в копии -
и выслать подтверждение
или
Тюрин Дмитрий
Сайт управляется системой
uCoz