Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 [9] 10 11 12 13 .. 25   вперед  Ctrl
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Dimitry Sibiryakov

Насколько я понимаю, эта строчка относится к запросу внутри exists. Я
уже поздравлял инженеров MS, сумевших выполнить этот запрос
телепатически, ничего не читая.


Гм... Проверку можно делать и не читая индекс, а обратившись к статистике по нему.
26 авг 08, 16:52    [6111112]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Николай1
Member

Откуда: Москва
Сообщений: 495
Dihotom
Николай1
Вообще-то, пользователь, вводящий документ, уже авторизован, потому как пароль он вводил при входе в базу/приложение. Соответсвенно, ссылка на этого пользователя должна быть обязательно схоранена в базе, что бы потом было известно, кому должно стать "мучительно больно". А из этого следует, что вся необходимая информация в триггере у нас есть.
Если Ваша система постоена по-другому - мои соболезнования.

Как говорил мой незабвенный преподаватель математики "Идитя и учитя!".

ЗЫ. А уж пользователь вводящий пароль в открытой транзакции - песнь песней. А если он в это время покурить пойдет?

ЗЫ2. Сдавайтесь, пока еще больших глупостей не наговорили.

Я бы посоветовал смотреть на примеры несколько шире. И пользователя, и его пароль не нужно воспринимать буквально. Смысл в том, что пользователь может настроить (и не хранить его в БД) поведение системы в случае возникновения сбоя.


Не может.
Данные, сохраняемые в БД - самодостаточны.
Если это не так, то это не БД, а что-то очень странное.
26 авг 08, 16:58    [6111158]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54790

pkarklin

Проверку можно делать и не читая индекс, а обратившись к статистике по нему.

Опять же телепатически. Размер статистики для уникального индекса пары
миллионов записей не подскажете?

Posted via ActualForum NNTP Server 1.4

26 авг 08, 17:01    [6111185]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Николай1
Member

Откуда: Москва
Сообщений: 495
Dihotom
Николай1
Триггер должен сделать все, что он может, для успешного завершения транзакции

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

Николай1
и, если триггер "не смог", то это необходимое и достаточное условие для отката транзакции.

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


Тригеру должно быть пофиг, в рамках какой транзакции он работает, все что ему нужно - уже есть в базе данных. Все остальное - от лукавого.
26 авг 08, 17:01    [6111189]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Dihotom
Member

Откуда:
Сообщений: 453
Николай1
Блин. Повторю - не во всех СУБД триггеры выполняются _сразу_ после оператора, который вызывает их выполнение. Момент получения ошибки из триггера - не определен. Гарантировано только то, что все триггеры выполнятся к моменту _завершения_ транзакции.

ЗЫ. Можно вспомнить, например, о deffefed и nodeffered, если я ничего не напутал.


Тогда, пардон, в таких СУБД Вы и не реализуете ветвление транзакции в зависимости от возникающих ошибок в триггере. Рискну предположить, что триггеры в таких СУБД и не должны заниматься проверкой целостности. Кстати, можно пример таких СУБД?

Николай1
Пример _рабочего_ кода, с вызовом альтернативного пути выполненения транзакции я так и не увидел. Рекурсивный try {} catch {} как-то не впечатляет.

А что конкретно в моем примере Вам не понравилось? Есть внешние условия, недоступные триггеру (i), есть сам триггер (some_func), генерирующий исключение в случае нарушения целостности, есть обработчик исключений, который в зависимости от внешних условий (i), недоступных триггеру, запускает альтернативную ветку (основной блок if) или откатывает (блок else) транзакцию. В альтернативной ветке у меня указан в комментарии только COMMIT, но туда можно и последовательность альтернативных операторов вписать.
И где Вы увидели там рекурсию?
26 авг 08, 17:02    [6111195]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Dihotom
Member

Откуда:
Сообщений: 453
Николай1
Не может.
Данные, сохраняемые в БД - самодостаточны.
Если это не так, то это не БД, а что-то очень странное.

Про самодостаточность данных я не спорю, даже не затрагивал эту тему.
Речь идет о переводе данных из одного состояния в другое. Т.е. не о данных, а о процессе, который может быть настроен как угодно - в том числе, и управляться пользователем. У Вас что, данные из одного определенного состояния могут перейти только в строго одно другое определенное? :)
26 авг 08, 17:06    [6111231]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Dihotom
Member

Откуда:
Сообщений: 453
Николай1
Тригеру должно быть пофиг, в рамках какой транзакции он работает, все что ему нужно - уже есть в базе данных. Все остальное - от лукавого.

Это, извините, вообще странное утверждение.
Я транзакцию на клиенте начинаю, например. Посылаю запросы СУБД. Каким образом триггер узнает, удалось мне на клиенте создать временный файл file.tmp, чтобы залогировать ошибку триггера или не удалось? Если удалось, то мы её логируем и завершаем транзакцию. Если не удалось - откатываем.
26 авг 08, 17:10    [6111277]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Dimitry Sibiryakov

Опять же телепатически. Размер статистики для уникального индекса пары
миллионов записей не подскажете?


DBCC SHOW_STATISTICS ('dbo.Object', Object_ID_XPK);

Name                                                                                                                             Updated              Rows                 Rows Sampled         Steps  Density                  Average key length       String Index 
-------------------------------------------------------------------------------------------------------------------------------- -------------------- -------------------- -------------------- ------ ------------------------ ------------------------ ------------
Object_ID_XPK авг 26 2008 5:30AM 118206241 118206241 135 1.0 8.0 NO

All density Average Length Columns
------------------------ ------------------------ ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
8.4597902E-9 8.0 ID

RANGE_HI_KEY RANGE_ROWS EQ_ROWS DISTINCT_RANGE_ROWS AVG_RANGE_ROWS
-------------------- ------------------------ ------------------------ -------------------- ------------------------
1 0.0 1.0 0 1.0
547804000 524486.0 1.0 524486 1.0
3559614000 1048575.0 1.0 1048575 1.0
8203333000 2359295.0 1.0 2359295 1.0
10344912000 524287.0 1.0 524287 1.0
12154317000 1048575.0 1.0 1048575 1.0
13522515000 524287.0 1.0 524287 1.0
16637518000 524287.0 1.0 524287 1.0
17187784000 524287.0 1.0 524287 1.0
18427483000 786431.0 1.0 786431 1.0
19978222000 524287.0 1.0 524287 1.0
21686266000 1048575.0 1.0 1048575 1.0
49092719000 786431.0 1.0 786431 1.0
77976646000 524287.0 1.0 524287 1.0
121700864000 524287.0 1.0 524287 1.0
165547906000 786431.0 1.0 786431 1.0
188824863000 524287.0 1.0 524287 1.0
202313770000 524287.0 1.0 524287 1.0
219133369000 786431.0 1.0 786431 1.0
233892959000 524287.0 1.0 524287 1.0
246493659000 524287.0 1.0 524287 1.0
289798543000 524287.0 1.0 524287 1.0
302521897000 524287.0 1.0 524287 1.0
309760306000 524287.0 1.0 524287 1.0
323528437000 524287.0 1.0 524287 1.0
327910309000 524287.0 1.0 524287 1.0
339225920000 786431.0 1.0 786431 1.0
354317681000 1310719.0 1.0 1310719 1.0
361181970000 524287.0 1.0 524287 1.0
398690082000 786431.0 1.0 786431 1.0
401073519000 524287.0 1.0 524287 1.0
402770401000 524287.0 1.0 524287 1.0
405612292000 786431.0 1.0 786431 1.0
406967488000 262143.0 1.0 262143 1.0
408773575000 786431.0 1.0 786431 1.0
410220281000 786431.0 1.0 786431 1.0
416410117000 786431.0 1.0 786431 1.0
419076904000 1572863.0 1.0 1572863 1.0
420520597000 786431.0 1.0 786431 1.0
423084095000 1572863.0 1.0 1572863 1.0
427222048000 786431.0 1.0 786431 1.0
428890154000 786431.0 1.0 786431 1.0
432169750000 2097151.0 1.0 2097151 1.0
461173520000 786431.0 1.0 786431 1.0
463277837000 1310719.0 1.0 1310719 1.0
466977340000 524287.0 1.0 524287 1.0
470612418000 1048575.0 1.0 1048575 1.0
471435956000 524287.0 1.0 524287 1.0
472880856000 786431.0 1.0 786431 1.0
478665063000 786431.0 1.0 786431 1.0
481901234000 1310719.0 1.0 1310719 1.0
483505382000 524287.0 1.0 524287 1.0
485369834000 524287.0 1.0 524287 1.0
487550045000 524287.0 1.0 524287 1.0
489445034000 524287.0 1.0 524287 1.0
490365930000 524287.0 1.0 524287 1.0
493375285000 786431.0 1.0 786431 1.0
496871864000 524287.0 1.0 524287 1.0
500559630000 1048575.0 1.0 1048575 1.0
507709288000 1048575.0 1.0 1048575 1.0
510708431000 524287.0 1.0 524287 1.0
518532381000 3670015.0 1.0 3670015 1.0
521487569000 524287.0 1.0 524287 1.0
523906622000 524287.0 1.0 524287 1.0
527504937000 524287.0 1.0 524287 1.0
547047890000 524287.0 1.0 524287 1.0
557321830000 524287.0 1.0 524287 1.0
560398754000 524287.0 1.0 524287 1.0
564358165000 524287.0 1.0 524287 1.0
567517801000 524287.0 1.0 524287 1.0
575577951000 524287.0 1.0 524287 1.0
576430315000 524287.0 1.0 524287 1.0
578060285000 1572863.0 1.0 1572863 1.0
578962682000 524287.0 1.0 524287 1.0
581370995000 524287.0 1.0 524287 1.0
582034573000 524287.0 1.0 524287 1.0
583596733000 524287.0 1.0 524287 1.0
607157323000 1048575.0 1.0 1048575 1.0
611644659000 524287.0 1.0 524287 1.0
629323899000 524287.0 1.0 524287 1.0
633371265000 524287.0 1.0 524287 1.0
634970213000 524287.0 1.0 524287 1.0
635528387000 524287.0 1.0 524287 1.0
636898738000 524287.0 1.0 524287 1.0
640806971000 524287.0 1.0 524287 1.0
652145662000 524287.0 1.0 524287 1.0
653234252000 1048575.0 1.0 1048575 1.0
654136644000 524287.0 1.0 524287 1.0
654943216000 524287.0 1.0 524287 1.0
662315616000 3670015.0 1.0 3670015 1.0
663444002000 524287.0 1.0 524287 1.0
665506464000 1048575.0 1.0 1048575 1.0
671246676000 2621439.0 1.0 2621439 1.0
679608195000 524287.0 1.0 524287 1.0
686615283000 1048575.0 1.0 1048575 1.0
692208635000 524287.0 1.0 524287 1.0
700096436000 524287.0 1.0 524287 1.0
702713572000 524287.0 1.0 524287 1.0
706765089000 1572863.0 1.0 1572863 1.0
708287187000 524287.0 1.0 524287 1.0
711279049000 524287.0 1.0 524287 1.0
723685853000 524287.0 1.0 524287 1.0
724750837000 524287.0 1.0 524287 1.0
726561273000 524287.0 1.0 524287 1.0
727872973000 524287.0 1.0 524287 1.0
734423404000 3145727.0 1.0 3145727 1.0
735840554000 524287.0 1.0 524287 1.0
737413549000 524287.0 1.0 524287 1.0
738533314000 524287.0 1.0 524287 1.0
742360156000 524287.0 1.0 524287 1.0
743506282000 524287.0 1.0 524287 1.0
744523523000 524287.0 1.0 524287 1.0
745294145000 524287.0 1.0 524287 1.0
746717271000 1048575.0 1.0 1048575 1.0
752404198000 2097151.0 1.0 2097151 1.0
756031099000 1572863.0 1.0 1572863 1.0
756906766000 524287.0 1.0 524287 1.0
758454657000 524287.0 1.0 524287 1.0
761039597000 1048575.0 1.0 1048575 1.0
761876656000 524287.0 1.0 524287 1.0
769906608000 3670015.0 1.0 3670015 1.0
781547285000 786431.0 1.0 786431 1.0
783376440000 786431.0 1.0 786431 1.0
785581900000 786431.0 1.0 786431 1.0
796768674000 4718591.0 1.0 4718591 1.0
805283166000 1572863.0 1.0 1572863 1.0
809010036000 1572863.0 1.0 1572863 1.0
811856092000 786431.0 1.0 786431 1.0
813995723000 786431.0 1.0 786431 1.0
819398718000 1572863.0 1.0 1572863 1.0
823753759000 1572863.0 1.0 1572863 1.0
827818949000 1572863.0 1.0 1572863 1.0
830139321000 786431.0 1.0 786431 1.0
832054867000 765527.0 1.0 765527 1.0
832054869000 0.0 1.0 0 1.0
26 авг 08, 17:34    [6111476]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Dihotom
Member

Откуда:
Сообщений: 453
Николай1
Dihotom
Вам на C++ пример или на Java? :)
int i = 2;

try
{
    some_func(); // типа наш триггер, в котором возникает исключение - ни о каком i он не знает
}
catch (...)
{
    if (i % 2 = 0)
    {
        // все хорошо, транзакцию завершаем
    }
    else
    {
        // все плохо, транзакцию откатываем
    }
}


Ну, ничего чудесного я не увидел.
Теперь вопрос - как из "все плохо" вы сделаете что-то для возможной починки и успешного альтернативного завершения транзакции? Если весь код по этому завершению лежит внутри try {}?

Прошу прощения, проглядел этот пост.
Вы, видимо, не совсем поняли идею, которую я хотел изобразить (наверно, комментарий "всё хорошо" с толку сбил). "Всё плохо" реально-то случилось в триггере (some_func) - он обнаружил нарушение целостности и сгенерировал исключение. Мы в обработчике ошибок поймали это исключение, проанализировали внешние условия (if ...) и приняли решение: попытаться завершить транзакцию по альтернативной ветке (основной блок if) или же откатить её (блок else).
26 авг 08, 17:34    [6111480]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
hvlad
Member

Откуда:
Сообщений: 11554
pkarklin
Dimitry Sibiryakov

Насколько я понимаю, эта строчка относится к запросу внутри exists. Я
уже поздравлял инженеров MS, сумевших выполнить этот запрос
телепатически, ничего не читая.


Гм... Проверку можно делать и не читая индекс, а обратившись к статистике по нему.
Cтатистика - лженаука. Это знают даже в МС :)
26 авг 08, 17:42    [6111533]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Николай1
Member

Откуда: Москва
Сообщений: 495
Dihotom
Николай1
Не может.
Данные, сохраняемые в БД - самодостаточны.
Если это не так, то это не БД, а что-то очень странное.

Про самодостаточность данных я не спорю, даже не затрагивал эту тему.
Речь идет о переводе данных из одного состояния в другое. Т.е. не о данных, а о процессе, который может быть настроен как угодно - в том числе, и управляться пользователем. У Вас что, данные из одного определенного состояния могут перейти только в строго одно другое определенное? :)


Если я ничего не путаю, то теория конечных автоматов построена именно на этом. А что?
26 авг 08, 17:45    [6111558]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Николай1
Member

Откуда: Москва
Сообщений: 495
Dihotom
Николай1
Блин. Повторю - не во всех СУБД триггеры выполняются _сразу_ после оператора, который вызывает их выполнение. Момент получения ошибки из триггера - не определен. Гарантировано только то, что все триггеры выполнятся к моменту _завершения_ транзакции.

ЗЫ. Можно вспомнить, например, о deffefed и nodeffered, если я ничего не напутал.


Тогда, пардон, в таких СУБД Вы и не реализуете ветвление транзакции в зависимости от возникающих ошибок в триггере. Рискну предположить, что триггеры в таких СУБД и не должны заниматься проверкой целостности. Кстати, можно пример таких СУБД?

Николай1
Пример _рабочего_ кода, с вызовом альтернативного пути выполненения транзакции я так и не увидел. Рекурсивный try {} catch {} как-то не впечатляет.

А что конкретно в моем примере Вам не понравилось? Есть внешние условия, недоступные триггеру (i), есть сам триггер (some_func), генерирующий исключение в случае нарушения целостности, есть обработчик исключений, который в зависимости от внешних условий (i), недоступных триггеру, запускает альтернативную ветку (основной блок if) или откатывает (блок else) транзакцию. В альтернативной ветке у меня указан в комментарии только COMMIT, но туда можно и последовательность альтернативных операторов вписать.
И где Вы увидели там рекурсию?


Ну, в catch надо же как-то завешать транзакцию? А где гарантия, что при этом не возникнут новые исключения?
26 авг 08, 17:47    [6111574]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Николай1
Member

Откуда: Москва
Сообщений: 495
Dihotom
Николай1
Тригеру должно быть пофиг, в рамках какой транзакции он работает, все что ему нужно - уже есть в базе данных. Все остальное - от лукавого.

Это, извините, вообще странное утверждение.
Я транзакцию на клиенте начинаю, например. Посылаю запросы СУБД. Каким образом триггер узнает, удалось мне на клиенте создать временный файл file.tmp, чтобы залогировать ошибку триггера или не удалось? Если удалось, то мы её логируем и завершаем транзакцию. Если не удалось - откатываем.


Про отложенный контроль целостности слышали?
И чего будет стоить запись в логе об успешном завершении, если при завершении транзакции возникнут проблемы с целостностью?
26 авг 08, 17:48    [6111580]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Николай1
Member

Откуда: Москва
Сообщений: 495
Dihotom
Николай1
Dihotom
Вам на C++ пример или на Java? :)
int i = 2;

try
{
    some_func(); // типа наш триггер, в котором возникает исключение - ни о каком i он не знает
}
catch (...)
{
    if (i % 2 = 0)
    {
        // все хорошо, транзакцию завершаем
    }
    else
    {
        // все плохо, транзакцию откатываем
    }
}


Ну, ничего чудесного я не увидел.
Теперь вопрос - как из "все плохо" вы сделаете что-то для возможной починки и успешного альтернативного завершения транзакции? Если весь код по этому завершению лежит внутри try {}?

Прошу прощения, проглядел этот пост.
Вы, видимо, не совсем поняли идею, которую я хотел изобразить (наверно, комментарий "всё хорошо" с толку сбил). "Всё плохо" реально-то случилось в триггере (some_func) - он обнаружил нарушение целостности и сгенерировал исключение. Мы в обработчике ошибок поймали это исключение, проанализировали внешние условия (if ...) и приняли решение: попытаться завершить транзакцию по альтернативной ветке (основной блок if) или же откатить её (блок else).


Я то как раз все понял. Поэтому и спросил - на какой глубине закончатся "альтернативные ветки" ?
26 авг 08, 17:50    [6111591]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Dihotom
Member

Откуда:
Сообщений: 453
Николай1
Если я ничего не путаю, то теория конечных автоматов построена именно на этом. А что?

Вы отрицаете существование транзакций, которые в зависимости от условий могут внести либо одну запись в БД, либо две?

Николай1
Ну, в catch надо же как-то завешать транзакцию? А где гарантия, что при этом не возникнут новые исключения?

Конечно, надо. Никаких гарантий нет - могут возникнуть. Именно поэтому речь идет о попытке завершения транзакции альтернативным способом. В противном случае, я бы утверждал, что откатов вообще не бывает.

Николай1
Про отложенный контроль целостности слышали?
И чего будет стоить запись в логе об успешном завершении, если при завершении транзакции возникнут проблемы с целостностью?

Опять Вы придираетесь к примеру. Ну, хорошо, я создам временный файл, залогирую ошибку и попытаюсь тем или иным способм восстановить целостность. Далее, как я описал - не удалось создать файл - откат. Но не триггер принимает решение.
Что касается отложенного контроля, то при чем он тут? Точно так же, на COMMIT будет сгенерировано исключение, которое можно обработать и решить - принимать попытку восстановить целостность и завершать транзакцию или нет.
26 авг 08, 17:58    [6111661]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
hamjak
Member

Откуда:
Сообщений: 11
MasterZiv

hamjak wrote:

Я решил вернуться обратно к конкретным проблемам конкретного человека.

> Написал всю БД в MySQL... но потом выяснилось что в триггерах невозможно
> использовать операторы отката или завершения транзакции. А мне это

На каких основаниях сделан такой вывод ? Пробовали ?
просто я прочитал сейчас документацию, запрещения ролбэков не нашел,
оно есть только у функций.

Да , какой engine используете ?


Во-первых, спасибо, что хоть кто-то вспомнил о моей проблеме. Во-вторых, 18 глава руководства в самом конце:
The trigger cannot use the CALL statement to invoke stored procedures that return data to the client or that use dynamic SQL. (Stored procedures are allowed to return data to the trigger through OUT or INOUT parameters.)

The trigger cannot use statements that explicitly or implicitly begin or end a transaction such as START TRANSACTION, COMMIT, or ROLLBACK.

Prior to MySQL 5.0.10, triggers cannot contain direct references to tables by name.
26 авг 08, 17:59    [6111671]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Dihotom
Member

Откуда:
Сообщений: 453
Николай1
Я то как раз все понял. Поэтому и спросил - на какой глубине закончатся "альтернативные ветки" ?

Решение за разработчиком. Логика альтернативного пути может быть сколько угодно сложной.
26 авг 08, 18:01    [6111686]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
Наш маленький флейм уже на первом месте на SQLруле.

В общем, я предлагаю сворачивать бесплодную дискуссию.
Я буду стараться в ней более не участвовать.
26 авг 08, 18:02    [6111702]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
Во-первых, спасибо, что хоть кто-то вспомнил о моей проблеме. Во-вторых, 18 глава руководства в самом конце:
The trigger cannot use the CALL statement to invoke stored procedures that return data to the client or that use dynamic SQL. (Stored procedures are allowed to return data to the trigger through OUT or INOUT parameters.)

The trigger cannot use statements that explicitly or implicitly begin or end a transaction such as START TRANSACTION, COMMIT, or ROLLBACK.

Prior to MySQL 5.0.10, triggers cannot contain direct references to tables by name.


Ну чего-то я этого не нашёл.
я читал F.1. Restrictions on Stored Routines and Triggers, там почему-то этого нет.
Хотя в указанной вами главе - да, я это нашёл.

Вы не на все вопросы ответили.
какой engine используете ?
Почему не понравилос исключение ?
26 авг 08, 18:08    [6111739]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

hamjak wrote:

> The trigger cannot use statements that explicitly or implicitly begin or
> end a transaction such as START TRANSACTION, COMMIT, or ROLLBACK.

Вот сейчас почитал, странно, такое ощущение, что на
клиенте нельзя поймать CONDITION, выброшенный в триггере (хотя окончательно
это утверждать не берусь).
Тогда тем более не понятно, как они предлагают обрабатывать
ошибки из триггеров.

Да, MySQL - всё же странный.

Posted via ActualForum NNTP Server 1.4

26 авг 08, 18:21    [6111823]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
Еще подумал.
Вы ведь можете не откатывать транзакцию, а сделать обратное действие в триггере.
Оно конечно суррогатно выглядит, но все же может быть тоже вариант.
26 авг 08, 18:22    [6111830]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Николай1
Member

Откуда: Москва
Сообщений: 495
Dihotom
Николай1
Если я ничего не путаю, то теория конечных автоматов построена именно на этом. А что?

Вы отрицаете существование транзакций, которые в зависимости от условий могут внести либо одну запись в БД, либо две?

Николай1
Ну, в catch надо же как-то завешать транзакцию? А где гарантия, что при этом не возникнут новые исключения?

Конечно, надо. Никаких гарантий нет - могут возникнуть. Именно поэтому речь идет о попытке завершения транзакции альтернативным способом. В противном случае, я бы утверждал, что откатов вообще не бывает.

Николай1
Про отложенный контроль целостности слышали?
И чего будет стоить запись в логе об успешном завершении, если при завершении транзакции возникнут проблемы с целостностью?

Опять Вы придираетесь к примеру. Ну, хорошо, я создам временный файл, залогирую ошибку и попытаюсь тем или иным способм восстановить целостность. Далее, как я описал - не удалось создать файл - откат. Но не триггер принимает решение.
Что касается отложенного контроля, то при чем он тут? Точно так же, на COMMIT будет сгенерировано исключение, которое можно обработать и решить - принимать попытку восстановить целостность и завершать транзакцию или нет.


Повторю вопрос еще раз - до какой глубины будут идти альтернативы? Фрактально?

Что касается COMMIT - если возникает нарушение ссылочной целостности при _завершении_ транзакции, то нельзя уже ничего сделать - данные из базы _уже_ будут откачены к моменту возвращения результата на клиента. О какой альтернативе может идти речь?

ЗЫ. Пожалуй я тоже сольюсь, что-то я устал задавать вопросы и не получать ответы.
26 авг 08, 18:53    [6111947]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
hamjak
Member

Откуда:
Сообщений: 11
MasterZiv
Вы не на все вопросы ответили.
какой engine используете ?
Почему не понравилос исключение ?

InnoDB
Да нет, почему вполне "понравилось".
Ребза, давайте сойдемся на мнении, что откат в триггерах исходя из конкретных условий и поставленных задач все же может иметь место. Повторюсь еще раз если в серве предусмотрено, то почему бы не использовать при определенных случаях. Почитав форум я понял, что не всегда оправдано, но ведь можно! А то простой вопрос: в MySQL можно использовать откат транзакций в триггере? вызвал целую войну!!https://www.sql.ru/forum/images/happy.gif! Ну хватит прям.
26 авг 08, 19:53    [6112093]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Dihotom
Member

Откуда:
Сообщений: 453
Николай1
Повторю вопрос еще раз - до какой глубины будут идти альтернативы? Фрактально?

Я ответил:
Dihotom
Решение за разработчиком. Логика альтернативного пути может быть сколько угодно сложной.

Николай1
Что касается COMMIT - если возникает нарушение ссылочной целостности при _завершении_ транзакции, то нельзя уже ничего сделать - данные из базы _уже_ будут откачены к моменту возвращения результата на клиента. О какой альтернативе может идти речь?

Я тут даже спорить не буду. Просто скажите мне, какое это имеет отношение к откату в триггере? И каким образом этот факт свидетельствует о премуществе 2-го подхода над 3-м (описание было выше)?
26 авг 08, 20:07    [6112117]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Николай1
Member

Откуда: Москва
Сообщений: 495
Dihotom
Николай1
Повторю вопрос еще раз - до какой глубины будут идти альтернативы? Фрактально?

Я ответил:
Dihotom
Решение за разработчиком. Логика альтернативного пути может быть сколько угодно сложной.

Ветка не может быть "сколь угодно сложной". Программирование - не математика, в нем нет бесконечностей.

Dihotom
Николай1
Что касается COMMIT - если возникает нарушение ссылочной целостности при _завершении_ транзакции, то нельзя уже ничего сделать - данные из базы _уже_ будут откачены к моменту возвращения результата на клиента. О какой альтернативе может идти речь?

Я тут даже спорить не буду. Просто скажите мне, какое это имеет отношение к откату в триггере? И каким образом этот факт свидетельствует о премуществе 2-го подхода над 3-м (описание было выше)?

Такое, что не очень понятно, как (и зачем) на клиенте разбираться, из-за чего (и в какой момент) возникла проблема. Что бы потом решить, откатывать транзакцию или продолжать дальше "по альтернативному пути".

В нормальных системах в таких случаях откатывают транзакцию, возвращают на клиента диагностику, предлагают что-то поменять в консерватории и повторить сохранение/исполнение.
26 авг 08, 23:08    [6112453]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 [9] 10 11 12 13 .. 25   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить