|
|
|
check с условием, выходящим за пределы одной записи: работает "через раз"
|
|||
|---|---|---|---|
|
#18+
hi all Есть вот такой изврат-с: Код: plaintext 1. 2. И теперь делаю несколько раз вот это: Код: plaintext Что на 2.5, что на сегодняшнем снапшоте (LI-T3.0.0.30981), - вижу одно и то же: первые НЕСКОЛЬКО команд прокатывают "на ура", записывая в таблицу значения, стопудово нарушающие чек. Дальше этот самы чек прочухивается и выдает ошибку, но опять-таки как-то "через раз": Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. В итоге, в таблице будут данные, которым этот чек - до фонаря: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. Только не говорите, что я извращенец - сам знаю Объясните лучше, это как такое может быть, что check видит нарушения как-то "через раз". PS. Если претензии к rand()-данным, то вот данные, которые ВСЕГДА проскакивают мимо этого чека: Код: plaintext 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2014, 20:28:40 |
|
||
|
check с условием, выходящим за пределы одной записи: работает "через раз"
|
|||
|---|---|---|---|
|
#18+
Таблоидэто как такое может быть, что check видит нарушения как-то "через раз". Ты в курсе, что он срабатывает перед вставкой записи в таблицу? Соответственно твой подзапрос для каждого нового f01 не выдаёт записей вообще. Как при этом срабатывает сравнение - я не в курсе. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2014, 20:42:45 |
|
||
|
check с условием, выходящим за пределы одной записи: работает "через раз"
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovТаблоидэто как такое может быть, что check видит нарушения как-то "через раз".Ты в курсе, что он срабатывает перед вставкой записи в таблицу? Разговор про это был тут, кажись (несколько лет взад); но я забыл, если честно. А насколько это "по стандарту" ? Разве не должен check проверять уже существующую запись (после всех before-триггеров, но перед всеми after-триггерами) ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2014, 20:49:35 |
|
||
|
check с условием, выходящим за пределы одной записи: работает "через раз"
|
|||
|---|---|---|---|
|
#18+
ТаблоидРазве не должен check проверять уже существующую запись (после всех before-триггеров, но перед всеми after-триггерами) ? Ты предлагаешь сначала вставлять в таблицу записи, не удовлетворяющие ограничениям, а потом старательно их вычищать?.. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2014, 20:53:27 |
|
||
|
check с условием, выходящим за пределы одной записи: работает "через раз"
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakovсначала вставлять в таблицу записи, не удовлетворяющие ограничениям, а потом старательно их вычищать?..Гм... тоже верно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2014, 21:05:06 |
|
||
|
check с условием, выходящим за пределы одной записи: работает "через раз"
|
|||
|---|---|---|---|
|
#18+
Сабж неинтересен, но ты собираешься таким образом реализовывать недавно заявленное ограничение на количество записей в группе ? Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2014, 23:00:46 |
|
||
|
check с условием, выходящим за пределы одной записи: работает "через раз"
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов РустамСабж неинтересен, но ты собираешься таким образом реализовывать недавно заявленное ограничение на количество записей в группе ?Не, это был по другому поводу вопрос. Задачу ограничения на число/сумму строк в группе через одну таблицу если и можно решить, то коряво как-то выходит. Еще и конкурентный доступ к к таблице надо учесть, ==> придется поле добавить, идентифицирующее текущую транзакцию Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. PS. Еще на таблицу надо бы триггер before update повесить: если old.f01 is NOT null and new.f01 is null - то выбросить исключение, иначе часть записей по одной и той же группе (TX) станет с незаполненными F01. PPS. Однако, это всё выглядит как карточный домик. Ибо никто не помешает ввести вот такое: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Не хватает check'a с отложенной проверкой, во! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2014, 00:46:23 |
|
||
|
check с условием, выходящим за пределы одной записи: работает "через раз"
|
|||
|---|---|---|---|
|
#18+
Таблоид> Задачу ограничения на число/сумму строк в группе Таблоид> через одну таблицу если и можно решить Это ты знатно задвинул, в своём духе, молодец. :) Таблоид> придется поле добавить, идентифицирующее текущую транзакцию Вовсе необязательно. Но да, денормализация с хранимым агрегатом упростила и ускорила бы реализацию, согласен. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2014, 00:59:40 |
|
||
|
check с условием, выходящим за пределы одной записи: работает "через раз"
|
|||
|---|---|---|---|
|
#18+
Никакой табличный чек никогда не решит задачу, касающуюся чего-либо кроме текущей строки таблицы. Прими это как аксиому. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2014, 01:52:09 |
|
||
|
check с условием, выходящим за пределы одной записи: работает "через раз"
|
|||
|---|---|---|---|
|
#18+
ТаблоидРазве не должен check проверять уже существующую запись (после всех before-триггеров, но перед всеми after-триггерами) ?Тебя сильно удивит тот факт, что "после before и до after триггеров" самой строки в таблице может ещё не быть ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2014, 01:55:32 |
|
||
|
check с условием, выходящим за пределы одной записи: работает "через раз"
|
|||
|---|---|---|---|
|
#18+
ТаблоидНе хватает check'a с отложенной проверкой, во!Пофигу. Изоляцию транзакций ещё никто не отменял. О грязном чтении даже не заикайся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2014, 01:56:43 |
|
||
|
check с условием, выходящим за пределы одной записи: работает "через раз"
|
|||
|---|---|---|---|
|
#18+
hvladТаблоидНе хватает check'a с отложенной проверкой, во!Пофигу. Изоляцию транзакций ещё никто не отменял. О грязном чтении даже не заикайся.В одной чем-то похожей задаче получилось сбацать "грязное чтение" через контекстные переменные. Но это работает только для sysdba. Жаль, что нет возможности создавать такие "свои" контекстные переменные, которые конкурентные транзакции / сессии могли бы читать (но не менять) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2014, 08:51:33 |
|
||
|
check с условием, выходящим за пределы одной записи: работает "через раз"
|
|||
|---|---|---|---|
|
#18+
hvlad, я бы вообще за select в check constraint как минимум порол. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2014, 12:31:47 |
|
||
|
check с условием, выходящим за пределы одной записи: работает "через раз"
|
|||
|---|---|---|---|
|
#18+
Таблоид, да, и может не совсем в кассу, но поскольку тут в чеке select sum по этой же таблице, напомню http://citforum.ru/database/classics/SQL_critiques/ "A5B (Искажение записи, Write Skew)" если я правильно помню, решается через deferred constraints. подробно про аномалии, включая lost update и прочее, тут http://www.sigmod.org/publications/sigmod-record/0409/2.ROAnomONeil.pdf ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2014, 12:45:36 |
|
||
|
check с условием, выходящим за пределы одной записи: работает "через раз"
|
|||
|---|---|---|---|
|
#18+
kdvрешается через deferred constraints.Нам, я так понимаю, deferred constr. не грозят... kdvподробно про аномалии, включая lost update и прочее, тут http://www.sigmod.org/publications/sigmod-record/0409/2.ROAnomONeil.pdf - затащил к себе в мемориз. Спасибо за тынц, не видел его раньше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2014, 12:58:56 |
|
||
|
check с условием, выходящим за пределы одной записи: работает "через раз"
|
|||
|---|---|---|---|
|
#18+
kdvhvlad, я бы вообще за select в check constraint как минимум порол.++ Пора расчехлять канделябры ;) kdv"A5B (Искажение записи, Write Skew)" если я правильно помню, решается через deferred constraints.См. выше про изоляцию тр-ций. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2014, 13:56:50 |
|
||
|
check с условием, выходящим за пределы одной записи: работает "через раз"
|
|||
|---|---|---|---|
|
#18+
hvladПора расчехлять канделябры ;)"Вы всё равно не остановите социалистических рабочих!" (С) к/ф "Однажды в Америке". Иметь сведения о том, что и как меняет (но еще не закоммитила) чужая транзакция, иногда необходимо. Как пример - создание бесконфликтной схемы остатков изделий, в которой должно всегда блюстись правило "Остаток >= 0". Бесконфликтной - значит, примерно такой, какую показывал DS тут . Но там речь шла об остатках контрагентов, а они могут быть как "положительными" так и "отрицательными" (мы должны / нам должны) - потому она и работоспособна. Если бы имелась возможность "подглядывать" за чужими незафиксированными изменениями, то такую схему (с контролем неотрицательности) можно было бы реализовать именно как бесконфликтную, т.е. без накопительного регистра остатков, в котором часты лок-конфликты за строку. Ясен пень, что допускать грязное чтение при вводе изменений в базу нельзя. Но вот сделать такое контекстные переменные - это было бы круто :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2014, 14:37:25 |
|
||
|
check с условием, выходящим за пределы одной записи: работает "через раз"
|
|||
|---|---|---|---|
|
#18+
ТаблоидЕсли бы имелась возможность "подглядывать" за чужими незафиксированными изменениями Таблоиддопускать грязное чтение при вводе изменений в базу нельзя.Казнить нельзя помиловать! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2014, 17:13:30 |
|
||
|
check с условием, выходящим за пределы одной записи: работает "через раз"
|
|||
|---|---|---|---|
|
#18+
Таблоиддопускать грязное чтение при вводе изменений в базу нельзя.Казнить нельзя помиловать![/quot]я подразумевал, что нельзя читать чужую грязь при выполнении DML-стейтментов. Но вот если чужаки вместе с незавершенными insert'ами создают/обновляют также и context-переменные в некотором namespace, которое (гипотетически) допускает ЧТЕНИЕ другими коннектами, то... почему бы не "почитать" ? :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2014, 17:30:40 |
|
||
|
check с условием, выходящим за пределы одной записи: работает "через раз"
|
|||
|---|---|---|---|
|
#18+
ТаблоиднезавершеннымиТаблоидпочему бы не "почитать"Потому что они незавершенные! Никак не въеду, как резон в полуфабрикате? обещать еще не значить жениться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2014, 17:38:24 |
|
||
|
check с условием, выходящим за пределы одной записи: работает "через раз"
|
|||
|---|---|---|---|
|
#18+
Ivan_PisarevskyНикак не въеду, как резон в полуфабрикате? обещать еще не значить жениться.У тебя 10 штук "чего-то-там". Транзакция-1 (далее Т1) пишет в свою GTT "корзину покупателя" 8 штук (но еще не коммитит). Транзакция-2 пишет в свою корзину 5 штук и коммитится. На складе при этом должно остаться 5 штук (я намеренно не упоминяю сейчас "регистр остатков" 0 просто: НА СКЛАДЕ). Т1 делает коммит. Если контроль неотрицательности отсутствует, то... это не система вообще. Если контроль неотрицательности лежит на check (qty_avaliable >= 0), то Т1 обломится (5 - 8 = -3), а покупатель и юзер потеряют время. Если же блокировать запись "регистра остатков" заблаговременно, как только Tx затолкала в корзинку изделие - это вообще труба. Зависнет эта самая "Tx" на пару часов - и что делать остальным ? Поэтому и маячит в воздухе идея не давать какой-то из транзакции вообще заносить в корзину изделие, если сейчас "видно", что его уже собираются хапнуть. Но это "видно" и есть грязное чтение. Реализовать его средствами DML - нельзя (и не нужно). Но вот реализовать его при некоторых доп. фичах rdb$get_context / rdb$set_context - можно было бы . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2014, 18:36:29 |
|
||
|
check с условием, выходящим за пределы одной записи: работает "через раз"
|
|||
|---|---|---|---|
|
#18+
ТаблоидНо вот реализовать его при некоторых доп. фичах rdb$get_context / rdb$set_context - можно было бы .А кто будет регулировать конкурентный доступ ? И, главное - как ? PS контроль неотрицательности в БД не имеет ничего общего с реальными движениями на складе. Открой для себя переучёты, пересортицу и прочую сермягу... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2014, 19:21:17 |
|
||
|
check с условием, выходящим за пределы одной записи: работает "через раз"
|
|||
|---|---|---|---|
|
#18+
hvladСм. выше про изоляцию тр-ций. я про то, что write skew не решается в snapshot. То есть, существуют аномалии в RC и SNAPSHOT, которые решаются повышением уровня изолированности вплоть до serializable. Нет в жизни счастья, бла-бла-бла. Просто такие вещи нужно знать и учитывать при разработке, вот и все. p.s. если с поиском в гугле на тему write skew все нормально, и третьим лезет интересный документ , а вот на тему read skew информации мало, разве что в приведенной мной "критике" пример A5A, и в статье Лили Козленко . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2014, 19:29:35 |
|
||
|
check с условием, выходящим за пределы одной записи: работает "через раз"
|
|||
|---|---|---|---|
|
#18+
hvladТаблоидНо вот реализовать его при некоторых доп. фичах rdb$get_context / rdb$set_context - можно было бы .А кто будет регулировать конкурентный доступ ? И, главное - как ?Перед тем, как затолкать в GTT очередную пару "Изделие, Кол-во", транзакция создает контекстную переменную с именем = 'part_' || :this_part_id и значением = cast( :this_amount as varchar). Затем она пробегает по mon$context_variables where mon$variable_name = 'part_' || :this_part_id и суммирует ВСЕ количества, которые сейчас там имеются по этому изделию. Если их сумма превышает stock->qty_avaliable, то exception. Только после этого делается insert into tmp$shopping_card. hvladОткрой для себя переучёты, пересортицу и прочую сермягу...Я знаю и про пересортицу (как от поставщика, так и "внутреннюю", когда сами кладовщики косячат), и про банальное воровство... Можно вообще убрать нахрен check qty >= 0, и на все вопросы отвечать "значит - спёрли!". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2014, 19:35:27 |
|
||
|
check с условием, выходящим за пределы одной записи: работает "через раз"
|
|||
|---|---|---|---|
|
#18+
Таблоиди суммирует ВСЕ количества, которые сейчас там имеются по этому изделию. Если их сумма превышает stock->qty_avaliable, то exception.(в предположении, что есть некоторое пространство имён, в котором контекстные переменные ЧУЖИХ транзакций могут быть прочитаны, но их нельзя менять) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2014, 19:37:08 |
|
||
|
|

start [/forum/topic.php?fid=40&msg=38593173&tid=1563785]: |
0ms |
get settings: |
7ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
186ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
56ms |
get tp. blocked users: |
1ms |
| others: | 210ms |
| total: | 486ms |

| 0 / 0 |
