powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / check с условием, выходящим за пределы одной записи: работает "через раз"
31 сообщений из 31, показаны все 2 страниц
check с условием, выходящим за пределы одной записи: работает "через раз"
    #38592338
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hi all

Есть вот такой изврат-с:
Код: plaintext
1.
2.
create sequence g;
recreate table t(id int primary key, f01 int, f02 int, constraint chk_f01_eq_f02_sum check(f01=(select sum(f02) from t tx where tx.f01 = t.f01)));
commit;
(т.е. значение в столбце f01 должно всегда быть равно сумме по столбу f02 для этого f01 :)).

И теперь делаю несколько раз вот это:
Код: plaintext
insert into t select gen_id(g,1),rand()*3,rand()*10 from rdb$types rows 1;

Что на 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.
SQL> insert into t select gen_id(g,1),rand()*3,rand()*10 from rdb$types rows 1;
SQL> insert into t select gen_id(g,1),rand()*3,rand()*10 from rdb$types rows 1;
Statement failed, SQLSTATE = 23000
Operation violates CHECK constraint CHK_F01_EQ_F02_SUM on view or table T
-At trigger 'CHECK_56'
SQL> insert into t select gen_id(g,1),rand()*3,rand()*10 from rdb$types rows 1;
SQL> insert into t select gen_id(g,1),rand()*3,rand()*10 from rdb$types rows 1;
SQL> insert into t select gen_id(g,1),rand()*3,rand()*10 from rdb$types rows 1;
SQL> insert into t select gen_id(g,1),rand()*3,rand()*10 from rdb$types rows 1;
Statement failed, SQLSTATE = 23000
Operation violates CHECK constraint CHK_F01_EQ_F02_SUM on view or table T
-At trigger 'CHECK_56'
SQL> insert into t select gen_id(g,1),rand()*3,rand()*10 from rdb$types rows 1;
Statement failed, SQLSTATE = 23000
Operation violates CHECK constraint CHK_F01_EQ_F02_SUM on view or table T
-At trigger 'CHECK_56'
SQL> insert into t select gen_id(g,1),rand()*3,rand()*10 from rdb$types rows 1;
Statement failed, SQLSTATE = 23000
Operation violates CHECK constraint CHK_F01_EQ_F02_SUM on view or table T
-At trigger 'CHECK_56'
SQL> insert into t select gen_id(g,1),rand()*3,rand()*10 from rdb$types rows 1;
Statement failed, SQLSTATE = 23000
Operation violates CHECK constraint CHK_F01_EQ_F02_SUM on view or table T
-At trigger 'CHECK_56'
SQL> insert into t select gen_id(g,1),rand()*3,rand()*10 from rdb$types rows 1;
Statement failed, SQLSTATE = 23000
Operation violates CHECK constraint CHK_F01_EQ_F02_SUM on view or table T
-At trigger 'CHECK_56'
SQL> insert into t select gen_id(g,1),rand()*3,rand()*10 from rdb$types rows 1;
SQL> insert into t select gen_id(g,1),rand()*3,rand()*10 from rdb$types rows 1;
Statement failed, SQLSTATE = 23000
Operation violates CHECK constraint CHK_F01_EQ_F02_SUM on view or table T
-At trigger 'CHECK_56'
SQL> insert into t select gen_id(g,1),rand()*3,rand()*10 from rdb$types rows 1;
SQL> insert into t select gen_id(g,1),rand()*3,rand()*10 from rdb$types rows 1;
Statement failed, SQLSTATE = 23000
Operation violates CHECK constraint CHK_F01_EQ_F02_SUM on view or table T
-At trigger 'CHECK_56'
SQL> insert into t select gen_id(g,1),rand()*3,rand()*10 from rdb$types rows 1;
SQL> insert into t select gen_id(g,1),rand()*3,rand()*10 from rdb$types rows 1;
Statement failed, SQLSTATE = 23000
Operation violates CHECK constraint CHK_F01_EQ_F02_SUM on view or table T
-At trigger 'CHECK_56'


В итоге, в таблице будут данные, которым этот чек - до фонаря:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
SQL> select * from t;

          ID          F01          F02
============ ============ ============
           9            2            8
          11            1            1
          12            0            8
          13            1            0
          19            3            3
          21            3            8
          23            1            3

SQL> select f01,sum(f02) from t group by f01 having f01  <>  sum(f02);
-- тут по идее не должно быть строк вообще, ибо таково условие чека!
         F01                   SUM
============ =====================
           0                     8
           1                     4
           2                     8
           3                    11

Только не говорите, что я извращенец - сам знаю
Объясните лучше, это как такое может быть, что check видит нарушения как-то "через раз".

PS. Если претензии к rand()-данным, то вот данные, которые ВСЕГДА проскакивают мимо этого чека:
Код: plaintext
1.
2.
 [code=plaintext]SQL> insert into t values(1, 1, 2);
SQL> insert into t values(2, 0, 2);
SQL> insert into t values(3, 3, 1);
...
Рейтинг: 0 / 0
check с условием, выходящим за пределы одной записи: работает "через раз"
    #38592346
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидэто как такое может быть, что check видит нарушения как-то "через раз".
Ты в курсе, что он срабатывает перед вставкой записи в таблицу? Соответственно твой
подзапрос для каждого нового f01 не выдаёт записей вообще. Как при этом срабатывает
сравнение - я не в курсе.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
check с условием, выходящим за пределы одной записи: работает "через раз"
    #38592352
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovТаблоидэто как такое может быть, что check видит нарушения как-то "через раз".Ты в курсе, что он срабатывает перед вставкой записи в таблицу? Разговор про это был тут, кажись (несколько лет взад); но я забыл, если честно.
А насколько это "по стандарту" ? Разве не должен check проверять уже существующую запись (после всех before-триггеров, но перед всеми after-триггерами) ?
...
Рейтинг: 0 / 0
check с условием, выходящим за пределы одной записи: работает "через раз"
    #38592353
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидРазве не должен check проверять уже существующую запись (после всех
before-триггеров, но перед всеми after-триггерами) ?
Ты предлагаешь сначала вставлять в таблицу записи, не удовлетворяющие ограничениям, а
потом старательно их вычищать?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
check с условием, выходящим за пределы одной записи: работает "через раз"
    #38592358
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakovсначала вставлять в таблицу записи, не удовлетворяющие ограничениям, а
потом старательно их вычищать?..Гм... тоже верно.
...
Рейтинг: 0 / 0
check с условием, выходящим за пределы одной записи: работает "через раз"
    #38592397
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сабж неинтересен, но ты собираешься таким образом реализовывать
недавно заявленное ограничение на количество записей в группе ?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
check с условием, выходящим за пределы одной записи: работает "через раз"
    #38592452
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов РустамСабж неинтересен, но ты собираешься таким образом реализовывать
недавно заявленное ограничение на количество записей в группе ?Не, это был по другому поводу вопрос.

Задачу ограничения на число/сумму строк в группе через одну таблицу если и можно решить, то коряво как-то выходит. Еще и конкурентный доступ к к таблице надо учесть, ==> придется поле добавить, идентифицирующее текущую транзакцию

Код: 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.
recreate sequence;
recreate table t(
  id int primary key, 
  tx int default  current_transaction  NOT null, 
  f01 int, 
  f02 int, 
  constraint chk_f01_equ_f02_sum 
    check( f01 is null 
              or 
              f01 = (select sum(x.f02) from t x where x.tx=t.tx and (x.f01 is null or x.f01=t.f01) ) 
         ) 
);
commit;

SQL> insert into t(id, f01, f02) select gen_id(g,1), null, rand()*20 from rdb$types rows 10;
SQL> select * from t;

          ID           TX          F01          F02
============ ============ ============ ============
         140        12328       <null>            6
         141        12328       <null>           16
         142        12328       <null>           17
         143        12328       <null>           17
         144        12328       <null>            1
         145        12328       <null>           11
         146        12328       <null>           12
         147        12328       <null>           13
         148        12328       <null>            4
         149        12328       <null>           19

-- Если сейчас read committed, то кто-то еще может добавить "свои" строки, закоммитить их и мы буде их видеть.
-- Чтобы отличить чужие строки от своих, добавляем условие по current_transaction:
SQL> update t set f01=(select sum(f02) from t x where  x.tx=current_transaction );
SQL> select * from t;

          ID           TX          F01          F02
============ ============ ============ ============
         140        12328          116            6
         141        12328          116           16
         142        12328          116           17
         143        12328          116           17
         144        12328          116            1
         145        12328          116           11
         146        12328          116           12
         147        12328          116           13
         148        12328          116            4
         149        12328          116           19

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.
SQL> update t set f01=(select sum(f02) from t x where x.tx=current_transaction)  order by rand() rows 5 ;
SQL> select * from t;

          ID           TX          F01          F02
============ ============ ============ ============
         150        12328       <null>           12
         151        12328          111            1
         152        12328          111           17
         153        12328          111            0
         154        12328          111           18
         155        12328          111            7
         156        12328       <null>            9
         157        12328       <null>           17
         158        12328       <null>           16
         159        12328       <null>           14
- и получаем частично незаполненные строки.

Не хватает check'a с отложенной проверкой, во!
...
Рейтинг: 0 / 0
check с условием, выходящим за пределы одной записи: работает "через раз"
    #38592462
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид> Задачу ограничения на число/сумму строк в группе
Таблоид> через одну таблицу если и можно решить

Это ты знатно задвинул, в своём духе, молодец. :)

Таблоид> придется поле добавить, идентифицирующее текущую транзакцию

Вовсе необязательно. Но да, денормализация с хранимым
агрегатом упростила и ускорила бы реализацию, согласен.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
check с условием, выходящим за пределы одной записи: работает "через раз"
    #38592475
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Никакой табличный чек никогда не решит задачу, касающуюся чего-либо кроме текущей строки таблицы.
Прими это как аксиому.
...
Рейтинг: 0 / 0
check с условием, выходящим за пределы одной записи: работает "через раз"
    #38592476
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидРазве не должен check проверять уже существующую запись (после всех before-триггеров, но перед всеми after-триггерами) ?Тебя сильно удивит тот факт, что "после before и до after триггеров" самой строки в таблице может ещё не быть ?
...
Рейтинг: 0 / 0
check с условием, выходящим за пределы одной записи: работает "через раз"
    #38592477
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидНе хватает check'a с отложенной проверкой, во!Пофигу.
Изоляцию транзакций ещё никто не отменял.
О грязном чтении даже не заикайся.
...
Рейтинг: 0 / 0
check с условием, выходящим за пределы одной записи: работает "через раз"
    #38592541
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladТаблоидНе хватает check'a с отложенной проверкой, во!Пофигу.
Изоляцию транзакций ещё никто не отменял.
О грязном чтении даже не заикайся.В одной чем-то похожей задаче получилось сбацать "грязное чтение" через контекстные переменные. Но это работает только для sysdba. Жаль, что нет возможности создавать такие "свои" контекстные переменные, которые конкурентные транзакции / сессии могли бы читать (но не менять)
...
Рейтинг: 0 / 0
check с условием, выходящим за пределы одной записи: работает "через раз"
    #38592794
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvlad,

я бы вообще за select в check constraint как минимум порол.
...
Рейтинг: 0 / 0
check с условием, выходящим за пределы одной записи: работает "через раз"
    #38592817
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

да, и может не совсем в кассу, но поскольку тут в чеке 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
...
Рейтинг: 0 / 0
check с условием, выходящим за пределы одной записи: работает "через раз"
    #38592837
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvрешается через deferred constraints.Нам, я так понимаю, deferred constr. не грозят...
kdvподробно про аномалии, включая lost update и прочее, тут http://www.sigmod.org/publications/sigmod-record/0409/2.ROAnomONeil.pdf - затащил к себе в мемориз. Спасибо за тынц, не видел его раньше.
...
Рейтинг: 0 / 0
check с условием, выходящим за пределы одной записи: работает "через раз"
    #38592900
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvhvlad,

я бы вообще за select в check constraint как минимум порол.++

Пора расчехлять канделябры ;)

kdv"A5B (Искажение записи, Write Skew)"
если я правильно помню, решается через deferred constraints.См. выше про изоляцию тр-ций.
...
Рейтинг: 0 / 0
check с условием, выходящим за пределы одной записи: работает "через раз"
    #38592962
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladПора расчехлять канделябры ;)"Вы всё равно не остановите социалистических рабочих!" (С) к/ф "Однажды в Америке".

Иметь сведения о том, что и как меняет (но еще не закоммитила) чужая транзакция, иногда необходимо.
Как пример - создание бесконфликтной схемы остатков изделий, в которой должно всегда блюстись правило "Остаток >= 0". Бесконфликтной - значит, примерно такой, какую показывал DS тут .
Но там речь шла об остатках контрагентов, а они могут быть как "положительными" так и "отрицательными" (мы должны / нам должны) - потому она и работоспособна.

Если бы имелась возможность "подглядывать" за чужими незафиксированными изменениями, то такую схему (с контролем неотрицательности) можно было бы реализовать именно как бесконфликтную, т.е. без накопительного регистра остатков, в котором часты лок-конфликты за строку.
Ясен пень, что допускать грязное чтение при вводе изменений в базу нельзя. Но вот сделать такое контекстные переменные - это было бы круто :-)
...
Рейтинг: 0 / 0
check с условием, выходящим за пределы одной записи: работает "через раз"
    #38593162
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидЕсли бы имелась возможность "подглядывать" за чужими незафиксированными изменениями
Таблоиддопускать грязное чтение при вводе изменений в базу нельзя.Казнить нельзя помиловать!
...
Рейтинг: 0 / 0
check с условием, выходящим за пределы одной записи: работает "через раз"
    #38593173
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоиддопускать грязное чтение при вводе изменений в базу нельзя.Казнить нельзя помиловать![/quot]я подразумевал, что нельзя читать чужую грязь при выполнении DML-стейтментов.
Но вот если чужаки вместе с незавершенными insert'ами создают/обновляют также и context-переменные в некотором namespace, которое (гипотетически) допускает ЧТЕНИЕ другими коннектами, то... почему бы не "почитать" ? :-)
...
Рейтинг: 0 / 0
check с условием, выходящим за пределы одной записи: работает "через раз"
    #38593178
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоиднезавершеннымиТаблоидпочему бы не "почитать"Потому что они незавершенные! Никак не въеду, как резон в полуфабрикате? обещать еще не значить жениться.
...
Рейтинг: 0 / 0
check с условием, выходящим за пределы одной записи: работает "через раз"
    #38593223
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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 - можно было бы .
...
Рейтинг: 0 / 0
check с условием, выходящим за пределы одной записи: работает "через раз"
    #38593258
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидНо вот реализовать его при некоторых доп. фичах rdb$get_context / rdb$set_context - можно было бы .А кто будет регулировать конкурентный доступ ? И, главное - как ?

PS контроль неотрицательности в БД не имеет ничего общего с реальными движениями на складе.
Открой для себя переучёты, пересортицу и прочую сермягу...
...
Рейтинг: 0 / 0
check с условием, выходящим за пределы одной записи: работает "через раз"
    #38593265
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladСм. выше про изоляцию тр-ций.
я про то, что write skew не решается в snapshot. То есть, существуют аномалии в RC и SNAPSHOT, которые решаются повышением уровня изолированности вплоть до serializable. Нет в жизни счастья, бла-бла-бла. Просто такие вещи нужно знать и учитывать при разработке, вот и все.

p.s. если с поиском в гугле на тему write skew все нормально, и третьим лезет интересный документ , а вот на тему read skew информации мало, разве что в приведенной мной "критике" пример A5A, и в статье Лили Козленко .
...
Рейтинг: 0 / 0
check с условием, выходящим за пределы одной записи: работает "через раз"
    #38593273
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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, и на все вопросы отвечать "значит - спёрли!".
...
Рейтинг: 0 / 0
check с условием, выходящим за пределы одной записи: работает "через раз"
    #38593276
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоиди суммирует ВСЕ количества, которые сейчас там имеются по этому изделию. Если их сумма превышает stock->qty_avaliable, то exception.(в предположении, что есть некоторое пространство имён, в котором контекстные переменные ЧУЖИХ транзакций могут быть прочитаны, но их нельзя менять)
...
Рейтинг: 0 / 0
check с условием, выходящим за пределы одной записи: работает "через раз"
    #38593586
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидhvladА кто будет регулировать конкурентный доступ ? И, главное - как ?Перед тем, как затолкать в GTT очередную пару "Изделие, Кол-во", транзакция создает контекстную переменную с именем = 'part_' || :this_part_id и значением = cast( :this_amount as varchar).
Затем она пробегает по mon$context_variables where mon$variable_name = 'part_' || :this_part_id и суммирует ВСЕ количества, которые сейчас там имеются по этому изделию.И пока она бегает, туда параллельно добавляют и убирают строки.

Это было бы смешно, если бы не было так нудно...
...
Рейтинг: 0 / 0
check с условием, выходящим за пределы одной записи: работает "через раз"
    #38593986
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидпишет в свою "корзину покупателя" 8 штук (но еще не коммитит)почему не коммитит? шоб веселей жилось?
ТаблоидНо это "видно" и есть грязное чтениеты путаешь бизнес транзакции и транзакции SQL сервера.

Если коммитить все, то не возникнет желания заниматься грязным чтением. внес клиент запись в свою корзинку, надо ее закоммитить и на регистр остатков можно навесить типа софт резерв.
...
Рейтинг: 0 / 0
check с условием, выходящим за пределы одной записи: работает "через раз"
    #38594110
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladЭто было бы смешно, если бы не было так нудно...Один раз что-то подобное всё-таки получилось . Да, там другая задача, но принцип тот же - через контексты. Правда, еще и db-level триггер нужен :-)
Как будет время - попробую сделать что-то на тему "неотрицательных остатков", как знать - вдруг попрёт...
...
Рейтинг: 0 / 0
check с условием, выходящим за пределы одной записи: работает "через раз"
    #38594113
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ivan_Pisarevskyвнес клиент запись в свою корзинку, надо ее закоммитить и на регистр остатков можно навесить типа софт резерв.Кто будет снимать этот soft-reserve в случае выпадения юзера, его создавшего, в долгую нирвану ? Доверять проверку на неактивность экземпляру приложения, который у него запущен, - нельзя (оно вообще может зависнуть или отвалиться от сети и проч).
Запускать по крону задание - это ставить приложение в зависимость от внешней среды (как минимум - от факта, что служба планировщика действительно работает, а также что само задание в ней не "почикали" случайно). Не очень гут, КМК...
ЗЫ. Кроме того, когда задание на грохание мягких резервов отработает и удалит к-л резерв, приложение должно непременно отреагировать на сиё, предупредить юзера. А это значит - отдельный поток с периодическим контролем записей, которые добавлялись юзером в корзину, с проверкой: "как там, вас не грохнули еще ?"
...
Рейтинг: 0 / 0
check с условием, выходящим за пределы одной записи: работает "через раз"
    #38594117
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидКто будет снимать этот soft-reserve в случае выпадения юзера, его
создавшего, в долгую нирвану ?
Ты же сам говорил: менеджер с более высоким приоритетом. Кроме того юзер же обычно не на
кладбище выпадает, рано или поздно он залогинится обратно и либо продолжит, либо таки
отменит свой заказ.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
check с условием, выходящим за пределы одной записи: работает "через раз"
    #38594169
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидЗапускать по крону заданиеЗачем? Достаточно тайштампа рядом с самим резервом, если ему менее 15 минут, то его никто не снимает, далее только менеджер, через полчаса-час уже могут снимать все кому не лень. На то оно и софт, что оно является периодическим реквизитом, а не списанием товара со склада.
Таблоидвыпадения юзера, его создавшего, в долгую нирвану ?плевать на юзера, время наше все, кто не успел, тот опоздал.

Периоды времени выбраны "с потолка", опять таки они могут зависеть от привилегий юзера, анониму резерв 5 минут, продвинутому 15, постоянному клиенту час и т.п.
...
Рейтинг: 0 / 0
31 сообщений из 31, показаны все 2 страниц
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / check с условием, выходящим за пределы одной записи: работает "через раз"
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]