fed: Ledger Balance Data in DAX

[bodeaux]

Здравствуйте.

Решил возобновить тему, чтобы еще раз попытаться разобраться с FieldUpdate = Relative

С помощью таких действий

static void Job_1(Args _args)
{
    Ltable t_1;    Ltable t_2;    Ltable t_3;;   
    // point_0
    ttsbegin;
    {// block_1
        select forupdate t_1 where t_1.id == 5;
        {// block_2
            select forupdate t_2 where t_2.id == 5;
            { // block_3
                select forupdate t_3 where t_3.id == 5;
                t_3.Val = 14;  t_3.update();
            }
            t_2.Val = 700;  t_2.update();
        }
        t_1.Val = 50000;  t_1.update();
    }
    ttscommit;
}

удалось установить, что в подобных случаях в таблице остается значение

W = V + (-V + U_1) + (-V + U_2) + ... + (-V + U_n),

где V - значение в точке point_0, U_i - значение, переданное в update номер i.

В частности, в самых интересных для практики случаях, которые обсуждались выше, получаем
1. i = 1 : W = U_1 (отличия от FieldUpdate = Absolute не видны).
2. i = 2 :
после первого запуска джоба имеем W = U_1 + U_2 - V
после второго запуска джоба имеем W = V
(любители арифметики могут убедиться, что при других i подобных циклов нет).
----------------------
Надеюсь, кто-нибудь сможет пояснить, для чего заложена именно такая формула для Relative update,
поскольку из предыдущего обсуждения мне показалось,
что люди ожидали работы по формуле W = V + U_1 + U_2 + ... + U_n.


В качестве офтопа еще хочу спросить, почему не возникает deadlock при выполнении block_2 после block_1.

[gl00mie]

Цитата:

Сообщение от bodeaux

удалось установить, что в подобных случаях в таблице остается значение W = V + (-V + U_1) + (-V + U_2) + ... + (-V + U_n), где V - значение в точке point_0, U_i - значение, переданное в update номер i.
Надеюсь, кто-нибудь сможет пояснить, для чего заложена именно такая формула для Relative update, поскольку из предыдущего обсуждения мне показалось, что люди ожидали работы по формуле W = V + U_1 + U_2 + ... + U_n.

Relative Update предполагает именно относительное изменение значения поля. Т.е. эта возможность работает "логично", когда вам не важно прежнее значение, а важно лишь приращение. Если бы у вас был такой код (обратите внимание на инкремент вместо присваивания):

select forupdate t_1 where t_1.id == 5;
{// block_2
    select forupdate t_2 where t_2.id == 5;
    { // block_3
        select forupdate t_3 where t_3.id == 5;
        t_3.Val += 14; t_3.update();
    }
    t_2.Val += 700; t_2.update();
}
t_1.Val += 50000; t_1.update();

То все отработало бы так, как ожидается, правда?

Цитата:

Сообщение от bodeaux

В качестве офтопа еще хочу спросить, почему не возникает deadlock при выполнении block_2 после block_1.

Блокировки нужны для синхронизации параллельного доступа к одним и тем же записям, а тут все все выборки forupdate происходят в рамках одного соединения с БД, поэтому deadlock не возникает: в рамках одного соединения синхронизировать по определению нечего. Более интересный вопрос: почему при обновлении в случае оптимистичной конкурентной модели не возникает конфликт обновления после block_3. Ответ на этот вопрос можно найти в книге Inside Dynamics AX 2009:

Цитата:

...К счастью, среда времени выполнения Microsoft Dynamics AX управляет данной ситуацией. При исполнении оператора обновления среда времени выполнения находит все другие буфера записей, содержащие ту же запись, и если при этом они были извлечены с ключевым словом forupdate, то среда времени выполнения изменяет значение поля RecVersion данных буферов записей на новое значение из базы данных. Следовательно, второе обновление не вызовет ошибки.

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

[AndyD]

Цитата:

Сообщение от gl00mie

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

Если верить подписи, то у bodeaux Ax3 SP4 без каких-либо KR.
Так что, убедиться будет проблематично