Возникла необходимость ознакомиться с Oracle

← →
Petr V. Abramov © (2006-06-07 23:59) [80]

Desdechado © (07.06.06 16:21) [73]
> Я делаю вывод, что "в процессе" - это и есть та самая блокировка.
" процессе" - это бред сивой кобылы, никому не нужный. т.к. порядок изменения произвольный. так что "блокирУй, не блокирУй, все равно получишь" ... ora-XXXX :)
и что за "флаг", который Вы обсуждаете???

а для анализа НАБОРА изменяемых записей ДО и ПОСЛЕ DML есть BEFORE и AFTER STATEMENT-LEVEL триггеры.

← →
Petr V. Abramov © (2006-06-08 00:03) [81]

> Desdechado ©
о если ответить более конкретно, то попасть должны значения из измененных записей новые, а из нетронутых - старые, поскольку для некоторых строк триггер уже сработал, а для некоторых - нет.
А мне кажется, что именно такойнабор данных очень хорошо сойдет в качестве определения белиберды.
потому как какое ему есть применение?

← →
evvcom © (2006-06-08 08:27) [82]

> Desdechado © (07.06.06 20:52) [79]
> Для такой ситуации важен порядок изменения записей, который
> можно явно определить в этом третьем срабатывании. А т.к.
> порядок неизвестный, то указанный в триггере запрос - бессмысленный.

Здесь 2 фразы, противоречащие друг другу, или я чего-то не понял? Порядок именно важен, но определить его нельзя! Он именно неизвестный, а запрос бессмысленный! А теперь подумай чуть дальше, ты уже сказал ключевую фразу: "запрос - бессмысленный"! Именно в таких случаях оракл и выдает ошибку о "мутации", которую мы уже так долго разбираем.

> Но если ответить более конкретно, то попасть должны значения
> из измененных записей новые, а из нетронутых - старые, ...

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

> и что за "флаг", который Вы обсуждаете???

Это внутренний флаг, недоступный программисту. Я о нем у Кайта читал, и проведенные эксперименты подтверждают, что он устанавливается именно в момент, указанный в алгоритме [76]. Т.е. если сделать select из той же таблицы в триггере before for each row для случая, когда изменяется/добавляется всего одна запись, ошибки не будет. И это объяснимо. Ведь еще ничего не изменилось.

← →
Desdechado © (2006-06-08 12:08) [83]

Petr V. Abramov © (08.06.06 00:03) [81]
evvcom © (08.06.06 08:27) [82]
Это определение белиберды я просто логически вывел, как ответ на вопрос ораклоида. Понятно, что такой запрос бессмысленен, о чем я и сказал. Но бессмысленен он не сам по себе, а в силу невозможности определить порядок изменения записей.
Но тем не менее, при срабатывании триггера на конкретной записи ведь есть уже записи измененные, а есть - неизмененные. О чем я и сказал. Понятно, что в этом случае логическая непротиворечивость и целостность данных не гарантируется, потому и запрос к ней блокируется. Но ведь запрос в триггере можно к этой таблице сделать такой, чтоб явно не затронуть изменяемые записи (уже измененные или еще не измененные, но направленные на изменение). Но Оракл и это блокирует. Что противно.

← →
ораклоид (2006-06-08 13:29) [84]

Desdechado © (08.06.06 12:08) [83]
Бессмысленных запросов не бывает, важно то, с какой целью делается тот или иной запрос. В данном случае цель была просто познавательная. Запрос синтаксису не противоречит, а значит он допустим и должен возвращать однозначный НД.
create or replace trigger TABLE_1_BUER before update on TABLE_1 for each row declare AnyCollection /*некая коллекция*/ begin delete from TABLE_1 t where t.id = :old.id; :new.id := 100; select t.id bulk collect into AnyCollection from TABLE_1 t; end;
И что д.б. в AnyCollection следуя Вашей логике? Хотя бы кол-во эл-тов? :-) А последовательность триггеров? Напишите? :-)

← →
Desdechado © (2006-06-08 13:39) [85]

Цитирую Desdechado © (08.06.06 12:08) [83]
Но бессмысленен он не сам по себе, а в силу невозможности определить порядок изменения записей.

А приведенный тобой триггер бессмысленен точно сам по себе. Даже с познавательной точки зрения. На что я процитирую себя еще раз запрос в триггере можно к этой таблице сделать такой, чтоб явно не затронуть изменяемые записи (уже измененные или еще не измененные, но направленные на изменение). Но Оракл и это блокирует. Что противно.

И прошу объяснить причину этого, а не уводить в сторону.

← →
evvcom © (2006-06-08 15:19) [86]

> потому и запрос к ней блокируется.

Не блокируется.

> Но ведь запрос в триггере можно к этой таблице сделать такой,
> чтоб явно не затронуть изменяемые записи (уже измененные
> или еще не измененные, но направленные на изменение). Но
> Оракл и это блокирует.

Не блокирует. Если ты вдруг (кстати можно это сэмулировать) из 2-ой сессии попытаешься обновить записи изменяемой в 1-ой сессии таблицы, отличные опять же от записей из 1-ой сессии, Оракл тебе отлуп не даст. Для 2-ой сессии таблица неизменяемая. Отлуп даст только если попытаешься обновить уже измененную из 1-ой сессии запись.
Такое объяснение доказывает тебе, что "мутация" - это не блокировка?

← →
ораклоид (2006-06-08 15:23) [87]

> Desdechado © (08.06.06 13:39) [85]
> запрос в триггере можно к этой таблице сделать такой, чтоб
> явно не затронуть изменяемые записи (уже измененные или
> еще не измененные, но направленные на изменение). Но Оракл
> и это блокирует. Что противно.

А как по Вашему Oracle может узнать о том, какие записи изменятся при выполнении запроса? Например, можете ли Вы утверждать, что при выполнении запроса update AnyTable set FieldName = AnyValue where ID = 1 запись с ID = 5 останется неизменной? Я - нет. Oracle - тоже. Например:
create or replace trigger TriggerName before update on TableName for each row begin execute immediate "update TableName set FieldName = null where ID = 5"; end;
В этом случае Oracle узнает об изменении записи с ID = 5 только в момент синтаксического разбора строкового выражения, которое произойдёт только в момент выполнения триггера на уже произошее событие before update. Так что всё далеко не так просто, как кажется изначально.

← →
Desdechado © (2006-06-08 15:43) [88]

evvcom © (08.06.06 15:19) [86]
Я говорил о той же самой транзакции, а не о какой-то другой сессии.

ораклоид (08.06.06 15:23) [87]
> всё далеко не так просто
Я и не утверждал, что просто. Имхо, лучше дать возможность изменений на усмотрение разработчика (пусть сам разгребает свои косые запросы с тройной модификацией тех же записей из каскадно срабатывающих триггеров), чем препятствовать ему выполнять нормальные запросы из соображений "как бы чего не вышло". Если оракл такой умный, зачем тогда в нем столько ошибок?

> Я говорил о той же самой транзакции, а не о какой-то другой
> сессии.

Просто ты утверждаешь, что это блокировка, а я доказываю, что нет, т.к. из другой сессии ошибку ты не получаешь.
Зря ты упираешься. Я так понимаю, что тебе уже просто не хочется признаваться, что фраза твоя об "оракле-блокировочнике" брошена то ли сгоряча, то ли в попыхах... Ты столкнулся с проблемой, толком в причинах не разобрался, это тебе не понравилось, вот и рубанул.
Продолжать этот спор в дальнейшем не вижу смысла. Если есть вопросы, могу ответить, объяснить, но спорить более не буду. Хочешь думать по-своему, твое дело...

Да я и не спорю вовсе. Просто хочется разобраться.

Ну и пожаловаться на эту хрень... :/

Методы обхода и способы обработки известны, норадости-то все равно не доставляют...

> Ну и пожаловаться на эту хрень... :/

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

> Методы обхода и способы обработки известны

Да не так уж и часто приходится ими пользоваться.

Если б он давал знать "по факту" обращения к измененным записям, а не в "подозрительных случаях".
А так уж очень он подозрительный, аж до маразма.

Возникла необходимость ознакомиться с Oracle Найти похожие ветки