Здравствуйте, GlebZ, Вы писали:

GZ>Просто нужен сервис который будет опрашивать сервера приложений через какой-то промежуток времени. В случае недоступности (а тут возможна некоторая усложненная процедура определения недоступности) то закрытие блокировок.

Да. Это понятно. Непонятна уже конкретная реализация процедуры определения недоступности. Я буду на CORBA все делать. Что, сделать просто метод ping() на сервере приложений, который ничего не делает, и периодически вызывать его из сервиса блокировок? Типа если системной ошибки CORBA не произошло, то усе окей?

GZ>Как только сервер-приложений вновь стал видимым, то он должен переслать свои блокировки еще раз. В случае невозможности блокирования — заинтересованные транзакции должны быть отбиты.

А вот это уже хуже. Так как если сервис блокировок, считая что сервер приложений сдох, снял его блокировки, то потом их восстанавливать уже нельзя. Так как время уже упущено.

S>>Да, еще дед-локи надо определять. Не так все тривиально получается.
GZ>А тут все просто.
GZ>Вариант 1.
GZ>Тебе на фиг не сдались ожидание разблокирования. Обычно в серверах приложений так и делают.

Не понял о чем ты.

GZ>Вариант 2.
GZ>Ожидание по некоторому небольшому timeout. В ожидании того, что конкурирующая транзакция достаточно коротка.
GZ>Вариант 3.
GZ>Наиболее сложный. Построение ациклического графа блокировок. Но спасибо Кодту, за готовую реализацию
GZ>Re[7]: Дедлоки!

Автор: Кодт
Дата: 21.10.04

Oracle вроде так делает: сначала ждет некоторое короткое время, и если за это время блокировка не освободилась, то начинает по графу определять дед-лок.

Я еще вот о чем. Ты сам говорил, и я здесь с тобой согласен, что всякие подвисания из-за блокировок необходимо показывать юзеру в виде, например, всплывающего окошка. Типа "Объект такой-то заблокирован тем-то. Ждите." Так вот не ждать же ему вечно. То есть в этом окошке должна быть кнопка "Задолбало ждать. Виг с ней, с этой транзакцией.". Ну и по этой кнопке клиент посылает на сервер приложений соответствующй сигнал, и сервер приложений прерывает процесс блокирования, а для прикладной программы генерится специальное исключение.

GZ>Или ты имел ввиду дедлоки БД?

Нет. Ты верно понял.

Здравствуйте, stalcer, Вы писали:

S>Да. Это понятно. Непонятна уже конкретная реализация процедуры определения недоступности. Я буду на CORBA все делать. Что, сделать просто метод ping() на сервере приложений, который ничего не делает, и периодически вызывать его из сервиса блокировок? Типа если системной ошибки CORBA не произошло, то усе окей?
Наверно да. Чем проще, тем лучше. Надо только проверить как работает CORBA. Для DCOM такого просто так не сделаешь. Он может зависнуть на несколько минут при посылке сообщения(на сколько зависает — в документации не описано, долго удивлялся на такое поведение).
Кстати, подобный сервис может еще для других вещей пригодится. Кто знает.

S>А вот это уже хуже. Так как если сервис блокировок, считая что сервер приложений сдох, снял его блокировки, то потом их восстанавливать уже нельзя. Так как время уже упущено.
Для тех-кто не сможет (блокировками заняты), придется так и так поубивать. Ну для остальных, чем им жить запрещать? Как недавно правильно замечали, ошибки канала и на локалке вещь достаточно частая.

S>>>Да, еще дед-локи надо определять. Не так все тривиально получается.
GZ>>А тут все просто.
GZ>>Вариант 1.
GZ>>Тебе на фиг не сдались ожидание разблокирования. Обычно в серверах приложений так и делают.

S>Не понял о чем ты.
О том, что пользователю сразу откатывают транзакцию и сообщают об этом.

S>Я еще вот о чем. Ты сам говорил, и я здесь с тобой согласен, что всякие подвисания из-за блокировок необходимо показывать юзеру в виде, например, всплывающего окошка. Типа "Объект такой-то заблокирован тем-то. Ждите." Так вот не ждать же ему вечно. То есть в этом окошке должна быть кнопка "Задолбало ждать. Виг с ней, с этой транзакцией.". Ну и по этой кнопке клиент посылает на сервер приложений соответствующй сигнал, и сервер приложений прерывает процесс блокирования, а для прикладной программы генерится специальное исключение.
А он о другом пользователе подумал? А если это генеральный директор? Этак можно до увольнительной донажиматься.
Варианты:
1. Все делает администратор. Пользователь звонит, так-то и так-то, хочу редактировать. У администратора есть инструмент. Он отбивает по своему усмотрению.
2. Не делал, но мысль показалась интересной. Выстраивается дерево подчинения (если в базе уже прописаны подчинение пользователей то удобно). Например: Администратор — высшая ступень. Он имеет право перебивать блокировки кому-угодно. Генеральный директор — может отбить блокировку кому-угодно кроме Администратора, замы ген. соответсвенно всем кроме генерального или администратора, и т.д.
Еще есть такая вещь. У блокировок есть время жизни. Обычно это нужно для offline клиентов. В случае если пользователь взял документ на редактирование, ушел из online и уехал. Например — на следующий день, если пользователь не предпринял действий, то блокировка снимается автоматически. Но здесь время блокировки зависит от самого бизнес-объекта.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

S>>А вот это уже хуже. Так как если сервис блокировок, считая что сервер приложений сдох, снял его блокировки, то потом их восстанавливать уже нельзя. Так как время уже упущено.
GZ>Для тех-кто не сможет (блокировками заняты), придется так и так поубивать. Ну для остальных, чем им жить запрещать? Как недавно правильно замечали, ошибки канала и на локалке вещь достаточно частая.

Дык за то время, пока сервер приложений считался убитым, и все его блокировки были сняты, объект сто раз изменить могли и уже подтвердить эти изменения, т.е. если даже все блокировки и наложить повторно — это все равно логически неверно.

GZ>О том, что пользователю сразу откатывают транзакцию и сообщают об этом.

А, понятно.

S>>Я еще вот о чем. Ты сам говорил, и я здесь с тобой согласен, что всякие подвисания из-за блокировок необходимо показывать юзеру в виде, например, всплывающего окошка. Типа "Объект такой-то заблокирован тем-то. Ждите." Так вот не ждать же ему вечно. То есть в этом окошке должна быть кнопка "Задолбало ждать. Виг с ней, с этой транзакцией.". Ну и по этой кнопке клиент посылает на сервер приложений соответствующй сигнал, и сервер приложений прерывает процесс блокирования, а для прикладной программы генерится специальное исключение.
GZ>А он о другом пользователе подумал? А если это генеральный директор? Этак можно до увольнительной донажиматься.

Да нет. Я же свою транзакцию имел ввиду. Т.е. пользователь нажимая на эту кнопку прерывает свою транзакцию. В старой версии системы "Эталон" такое было (новую я не видел). И у нас народ этим пользуется. А чего ждать-то бесконечно. Отменил да и нафиг. Занялся пока чем-нибудь другим.
Да, только такой подход может привести к длительным системным транзакциям.

Здравствуйте, Sinclair, Вы писали:

Что-то посмотрел как теоретически реализовать вариант 2.5. Хреновенько чего-то получается. И логика достаточно сложная, и запросы избыточны, а без статитики вообще каюк. Посмотрел старые записи, я оказывается не раз к нему возвращался. Только забивал на это дело.

Существуют ли какие-нибудь реализации п.1 и п 2.5?

С уважением, Gleb.

Здравствуйте, stalcer, Вы писали:

S>Да, только такой подход может привести к длительным системным транзакциям.
Поэтому, желательное условие — блокировка за пределами системной транзакции в самом начале бизнес-транзакции всем скопом (тогда еще возможна реализация развязки дедлоков малой кровью).

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GZ>Поэтому, желательное условие — блокировка за пределами системной транзакции в самом начале бизнес-транзакции всем скопом (тогда еще возможна реализация развязки дедлоков малой кровью).

Этот "скоп" (множество блокируемыз объектов) еще определить нужно. В большинстве случаев в начале бизнес-транзакции его определить как раз и нельзя. Т.к. пользователь выбирает его посредством GUI.

Здравствуйте, stalcer, Вы писали:

S>Этот "скоп" (множество блокируемыз объектов) еще определить нужно. В большинстве случаев в начале бизнес-транзакции его определить как раз и нельзя. Т.к. пользователь выбирает его посредством GUI.
Слушай, я сейчас подумал. В принципе, у транзакции существует и можно определить момент когда она становится пишущей. То есть, пользователь прочитал данные, начал редактировать. А если в этот момент переводить все S-блокировки в U. Просто, интересно твое мнение по применимости и возможности.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:
GZ>Слушай, я сейчас подумал. В принципе, у транзакции существует и можно определить момент когда она становится пишущей. То есть, пользователь прочитал данные, начал редактировать. А если в этот момент переводить все S-блокировки в U. Просто, интересно твое мнение по применимости и возможности.
Проблема в том, что такая стратегия с большой вероятностью приведет к дедлоку. U -блокировку нельзя наложить, пока есть чужая S-блокировка. Два процесса, выполняющих одинаковые сценарии, неизбежно друг друга запрут. Именно поэтому ввели U-блокировку в дополнение к S и X, чтобы можно было гарантировать ее конверсию в X, все еще разрешая наложение S.

Здравствуйте, Sinclair, Вы писали:

S>Проблема в том, что такая стратегия с большой вероятностью приведет к дедлоку. U -блокировку нельзя наложить, пока есть чужая S-блокировка.
Как раз наоборот. С помощью такой тактики, можно упорядочить последовательность блокировок и кардинально решить проблему блокировок.
S> гарантировать ее конверсию в X, все еще разрешая наложение S.
Ты что-то странное написал. Не понял.
С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, Sinclair, Вы писали:

GZ>Что-то посмотрел как теоретически реализовать вариант 2.5. Хреновенько чего-то получается. И логика достаточно сложная, и запросы избыточны, а без статитики вообще каюк.
Гм. Да вроде бы не очень нужна статистика-то. Тут ведь ".5" предполагается реализовать прямым перебором списка измененных объектов. Какая уж там статистика. Статистику пусть РСУБД внути себя ведет.
GZ> Посмотрел старые записи, я оказывается не раз к нему возвращался. Только забивал на это дело.

GZ>Существуют ли какие-нибудь реализации п.1 и п 2.5?
Если честно, то не в курсе. Ну вот Versant вроде как использует первый подход, судя по тому, что запросы в них на самом деле реляционные — скромно упоминая про невозможность использования методов объектов в запросах, они практически выдают реляционную природу своей серверной стороны. С другой стороны, там все-таки не вполне традиционная РСУБД стоит — некоторые фишечки там сделаны нарошно для оптимизации навигационнных запросов сделаны.

Здравствуйте, GlebZ, Вы писали:

S>>Проблема в том, что такая стратегия с большой вероятностью приведет к дедлоку. U -блокировку нельзя наложить, пока есть чужая S-блокировка.
GZ>Как раз наоборот. С помощью такой тактики, можно упорядочить последовательность блокировок и кардинально решить проблему блокировок.
S>> гарантировать ее конверсию в X, все еще разрешая наложение S.
GZ>Ты что-то странное написал. Не понял.
GZ>С уважением, Gleb.
Гм. Я может неправильно применяю термины, т.к. несколько отстал от вашей беседы Именование блокировок я трактую согласно доке от MS SQL Server. Концепция пессимистичного блокирования вместе с причинами введения промежуточных блокировок между shared и eXclusive кратко изложена вот здесь

Автор: Sinclair
Дата: 27.08.02

.

Здравствуйте, Sinclair, Вы писали:

S>Гм. Да вроде бы не очень нужна статистика-то. Тут ведь ".5" предполагается реализовать прямым перебором списка измененных объектов.
Прямой перебор не всегда возможен. Например:

SELECT A WHERE A.f>20 and A.B.f>10 AND A.B.C.f>20

при этом — у нас существуют в кэше набор добавленных С, при этом нет соответсвующих B. В результате, мы должны подгрузить все B которые завязаны на С. Ессно, навигационный доступ при этом не эффективен. Для измененных С — другая логика. В них уже можем что-то прогнозировать.
S>Какая уж там статистика. Статистику пусть РСУБД внути себя ведет.
Статистика уже желательна на этапе трансформации OQL в SQL. Если бы SQL не влиял на планы запросов, было-бы очень хорошо. Но это не так. Допустим:

SELECT A WHERE (A.B.F>20 AND A.C.F>20 AND A.C.F1=A.B.F1)

где A.B и A.C — коллекции.
В результате два варианта:

SELECT A.* FROM A 
WHERE 
    A.B IN (SELECT B.OID FROM WHERE B>20 AND 
        B.F1 IN (SELECT C.F1 FROM C WHERE C.F>20))

И

SELECT A.* FROM A 
WHERE 
    A.С IN (SELECT C.OID FROM C WHERE C.F>20 AND 
        с.F1 IN (SELECT B.F1 FROM WHERE B>20 ))

Стандартные БД не умеют развертывать такие запросы. А без информации о кардинальности, можно сделать очень неприлично долгий запрос.

GZ>>Существуют ли какие-нибудь реализации п.1 и п 2.5?
S>Если честно, то не в курсе. Ну вот Versant вроде как использует первый подход, судя по тому, что запросы в них на самом деле реляционные — скромно упоминая про невозможность использования методов объектов в запросах, они практически выдают реляционную природу своей серверной стороны. С другой стороны, там все-таки не вполне традиционная РСУБД стоит — некоторые фишечки там сделаны нарошно для оптимизации навигационнных запросов сделаны.
Борьба двухмерного дискового хранилища с многомерными объектами
Вообще, если бы были инструменты быстрого навигационного доступа, половину проблемы можно было-бы решить.

С уважением, Gleb.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, GlebZ, Вы писали:

S>>>Проблема в том, что такая стратегия с большой вероятностью приведет к дедлоку. U -блокировку нельзя наложить, пока есть чужая S-блокировка.
GZ>>Как раз наоборот. С помощью такой тактики, можно упорядочить последовательность блокировок и кардинально решить проблему блокировок.
Блин, сам описался. Ессно имелось ввиду проблему дедлоков. Да еще, ее можно не упрорядочить по наложению, а вообще сделать кооперативным (в каждый момент времени только одна транзакция конвертирует пакет блокировок).
S>>> гарантировать ее конверсию в X, все еще разрешая наложение S.
GZ>>Ты что-то странное написал. Не понял.
Как ты правильно заметил, гарантируется отсутсвие дедлоков при конверсии. Но гарантировать саму конверсию? Хотя это уже буквоедство.
S>Гм. Я может неправильно применяю термины, т.к. несколько отстал от вашей беседы Именование блокировок я трактую согласно доке от MS SQL Server. Концепция пессимистичного блокирования вместе с причинами введения промежуточных блокировок между shared и eXclusive кратко изложена вот здесь

Автор: Sinclair
Дата: 27.08.02

.
У нас здесь несколько другое. Нет запрещения на чтение, то бишь X блокировок. Плюс к этому ораклоидная сериализация без явного блокирования (считай что snapshot).

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, Sinclair, Вы писали:

S>>Гм. Да вроде бы не очень нужна статистика-то. Тут ведь ".5" предполагается реализовать прямым перебором списка измененных объектов.
GZ>Прямой перебор не всегда возможен. Например:
GZ>

GZ>SELECT A WHERE A.f>20 and A.B.f>10 AND A.B.C.f>20
GZ>

GZ>при этом — у нас существуют в кэше набор добавленных С, при этом нет соответсвующих B. В результате, мы должны подгрузить все B которые завязаны на С.
Надо подумать....
Упс, похоже мы вообще попали. Если у нас к примеру есть один миллион объектов типа A, и все эти A ссылаются на ровно один B, и по чистой случайности у нас именно этот B изменен в транзации (B.d = 5 вместо хранимого в СУБД d = 10), то результат запроса "select A where B.d = 5" не будет иметь никакого отношения к реальности. Увы, при этом перебор кэша не спасает — даже если мы и поймем, что запрос зависит именно от этого B, ничего полезного сделать уже нельзя — все данные про А по-прежнему сидят в базе, в кэше пусто. Упес пипиндур. Был неправ. Прошу срочно расстрелять меня за сортиром.
GZ>Статистика уже желательна на этапе трансформации OQL в SQL. Если бы SQL не влиял на планы запросов, было-бы очень хорошо. Но это не так. Допустим:
GZ>

GZ>SELECT A WHERE (A.B.F>20 AND A.C.F>20 AND A.C.F1=A.B.F1)
GZ>

GZ>где A.B и A.C — коллекции.
GZ>В результате два варианта:
GZ>

GZ>SELECT A.* FROM A 
GZ>WHERE 
GZ>    A.B IN (SELECT B.OID FROM WHERE B>20 AND 
GZ>        B.F1 IN (SELECT C.F1 FROM C WHERE C.F>20))
GZ>

GZ>И
GZ>

GZ>SELECT A.* FROM A 
GZ>WHERE 
GZ>    A.С IN (SELECT C.OID FROM C WHERE C.F>20 AND 
GZ>        с.F1 IN (SELECT B.F1 FROM WHERE B>20 ))
GZ>

GZ>Стандартные БД не умеют развертывать такие запросы. А без информации о кардинальности, можно сделать очень неприлично долгий запрос.
Гм. Вообще-то не стоит заниматься такими излишествами. Текст запроса должен быть таким:

select * from A 
inner join B on A.B = B.OID 
inner join C on A.C = C.OID
where C.F1 = B.F1
and B.F > 20 and C.F > 20

Уверяю — современный сервер вполне развернет такой запрос. И никаких проблем с кардинальностями не будет. А попытки вынудить сервер к определенному плану путем запутывания запросами — глупость. Лучеш выкинуть такую СУБД, и взять ту, которой можно доверять . Она ведь ради того и берется — иначе надо тупо на файлухе все делать.

Здравствуйте, Sinclair, Вы писали:

S>Надо подумать....
S>Упс, похоже мы вообще попали. Если у нас к примеру есть один миллион объектов типа A, и все эти A ссылаются на ровно один B, и по чистой случайности у нас именно этот B изменен в транзации (B.d = 5 вместо хранимого в СУБД d = 10), то результат запроса "select A where B.d = 5" не будет иметь никакого отношения к реальности. Увы, при этом перебор кэша не спасает — даже если мы и поймем, что запрос зависит именно от этого B, ничего полезного сделать уже нельзя — все данные про А по-прежнему сидят в базе, в кэше пусто. Упес пипиндур. Был неправ. Прошу срочно расстрелять меня за сортиром.
Во первых — сейчас это уже не модно. Вот замочить в сортире, это по путински.
Во-вторых — еще не все потеряно. В принципе, имея нормальный граф выполнения запроса, можно выделять важную информацию из кэша по B и строить избыточные запросы. Правда, сразу начинаются проблемы ограничения SQL по длине. И еще важна информация по измененному полю. Иначе придется генерить по всем B которые были изменены.
Ну в общем, ничего хорошего это не предвещает.

S>

S>select * from A 
S>inner join B on A.B = B.OID 
S>inner join C on A.C = C.OID
S>where C.F1 = B.F1
S>and B.F > 20 and C.F > 20
S>

S>Уверяю — современный сервер вполне развернет такой запрос. И никаких проблем с кардинальностями не будет. А попытки вынудить сервер к определенному плану путем запутывания запросами — глупость. Лучеш выкинуть такую СУБД, и взять ту, которой можно доверять . Она ведь ради того и берется — иначе надо тупо на файлухе все делать.
Забыл distinct поставить, но это уже мелочи. Вобщем у меня получались такие запросы, что хоть вешайся. В основном связано с обработкой IN. Сейчас на взгляд уже не помню. Надо дома посмотреть.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GZ>Слушай, я сейчас подумал. В принципе, у транзакции существует и можно определить момент когда она становится пишущей.

Согласен. Об этом ниже.

GZ>То есть, пользователь прочитал данные, начал редактировать. А если в этот момент переводить все S-блокировки в U. Просто, интересно твое мнение по применимости и возможности.

Как правильно заметил Sinclair, "shared" не всегда можно сконвертировать в "noshare". Именование блокировок отсюда

Автор: stalcer
Дата: 31.03.05

.

О моменте, когда транзакция становится пишущей:

Мне кажется, что ты все упрощаешь, говоря "пользователь прочитал данные, начал редактировать".
Я бы разделил бизнес транзакцию на следующие этапы:
1: Интерактивное взаимодействие с пользователем.
2: Окончательный рассчет + коммит.

Дык вот этап (1) — длительный (с перерывами на обеды и т.п. ). И на протяжении этого этапа пользователь при помощи GUI (а также и некоторой бизнес логики) может набирать данные, причем это не одно действие, т.е. он может открывать различные дополнительные справочники и т.п. То есть данные подчитываются на протяжении всего первого этапа. То есть на протяжении всего интерактивного диалога с пользователем.

Этап (2) — без интерактивного диалога с пользователем и поэтому относительно короткий. Здесь я думаю запускается финальный рассчет. Он тоже может подчитывать необходимые для рассчета данные.

Далее напомню, что у меня одна бизнес транзакция состоит из нескольких системных. В связи с чем встает вопрос об обеспечении атомарности изменений, сделанных бизнес транзакцией. Я предлагаю следующее решение этого вопроса:

— Вводим "временно хранимые объекты", как описано здесь

Автор: stalcer
Дата: 30.03.05

.
— На этапе (1) запрещаем изменение любых данных, кроме "временно хранимых объектов". Зато этот этап может быть длительным и состоять из нескольких системных транзакций.
— Этап (2) делаем из только одной системной транзакции, и в нем производим все необходимые модификации данных, на основе сформированных "временно хранимых объектов".

Такми образом — атомарность обеспечена.
Следует заметить, что на этапе (2) работает рассчет написанный прикладником, т.е. изменения реальных данных (на основе "временно хранимых объектов") система автоматически не делает. И вообще структура "временно хранимых объектов" не соответствует настоящим хранимым объектам. Т.е. временно хранимые объекты — это дополнительная сущность, с которой работает прикладная программа.

Мы тут на работе подумали, получается что большинство бизнес транзакций подходят под этот сценарий. Остальные также несложно подвести под него.

Это все про атомарность, не про блокировки. С блокировками я не согласен, потому-что я считаю, что блокировки необходимо накладывать по смыслу, т.е.:
— на те объекты, на которые по смыслу необходимо.
— в тот момент времени, в который по смыслу необходимо.

Однако, может в твоей идее с конвертацией блокировок и есть рациональное зерно. Но тогда необходимо под эту идею придумывать и типы блокировок. S и U блокировки здесь не подойдут.
Надо подумать...

Здравствуйте, GlebZ, Вы писали:

GZ>Как ты правильно заметил, гарантируется отсутсвие дедлоков при конверсии. Но гарантировать саму конверсию? Хотя это уже буквоедство.

Это не буквоедство, как раз сама конверсия во многих сдучаях и не пройдет.

Здравствуйте, GlebZ, Вы писали:

GZ>Во первых — сейчас это уже не модно. Вот замочить в сортире, это по путински.
GZ>Во-вторых — еще не все потеряно. В принципе, имея нормальный граф выполнения запроса, можно выделять важную информацию из кэша по B и строить избыточные запросы. Правда, сразу начинаются проблемы ограничения SQL по длине. И еще важна информация по измененному полю. Иначе придется генерить по всем B которые были изменены.
GZ>Ну в общем, ничего хорошего это не предвещает.
GZ>Забыл distinct поставить, но это уже мелочи.
Не нужен там никакой дистинкт. Inner join по FK/PK не вернет больше одной записи для A.
GZ>Вобщем у меня получались такие запросы, что хоть вешайся. В основном связано с обработкой IN. Сейчас на взгляд уже не помню. Надо дома посмотреть.
Ну, если честный OQL конвертить, то могут и не такие кошмары присниться. Товарищь Fegaras, например, считает, что надо план запроса строить статически — при компиляции. Он как раз собаку съел на оптимизации запросов типа "выбрать отделы, все менеджеры в которых старше среднего возраста своих подчиненных".

Здравствуйте, Sinclair, Вы писали:

GZ>>Вобщем у меня получались такие запросы, что хоть вешайся. В основном связано с обработкой IN. Сейчас на взгляд уже не помню. Надо дома посмотреть.
S>Ну, если честный OQL конвертить, то могут и не такие кошмары присниться.
Потому OQL и адаптируют, чтобы спать спокойно.
S>Товарищь Fegaras, например, считает, что надо план запроса строить статически — при компиляции. Он как раз собаку съел на оптимизации запросов типа "выбрать отделы, все менеджеры в которых старше среднего возраста своих подчиненных".
А я с ним согласен. (Это который Leonidas Feragas? Интересные статейки у него есть? Если не в лом дай ссылки).

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:
GZ>А я с ним согласен. (Это который Leonidas Feragas? Интересные статейки у него есть? Если не в лом дай ссылки).
Ссылок не дам — те, что у меня, скачаны с платного ACM. Если хочешь, то стукнись в icq 12209728 — я тебе их намылю.