The daily Axapta WTF

[gl00mie]

В D365FO семейство классов RAssetProposal очень "занятно" распаковывает параметры в unpack(), из-за чего не так просто добавлять в это семейство новые параметры для сохранения в pack()/unpack().
Коллега недавно наткнулся на проблему, пытаясь применить к этому семейству рекомендации по расширению наследников RunBase. В рекомендациях говорится, что в pack() вашего класса-расширения нужно написать примерено так:

public container pack()
{
    container packedClass = next pack();
    return SysPackExtensions::appendExtension(packedClass, classStr(MySysUserLogCleanup_Extension), this.myPack());
}

При этом - внимание! - в конец общего контейнера допишется еще один элемент-контейнер с параметрами вашего расширения. Если расширений несколько, то, вероятно, допишется не один элемент, а несколько. В unpack() же класса-расширения вам надо написать примерно вот так:

public boolean unpack(container _packedClass)
{
    boolean result = next unpack(_packedClass);
    if (result)
    {
        container myState = SysPackExtensions::findExtension(_packedClass, classStr(MySysUserLogCleanup_Extension));
        result = this.myUnpack(myState); //Also unpack the extension
    }
    return result;
}

Но в случае RAssetProposal следование официальной инструкции приводит к ошибке времени выполнения в расширяемом классе: невозможно инициализировать queryRun из контейнера.
Вот как бы вы работали с queryRun в pack/unpack? Обычно это выглядит так:

public container pack()
{
    return [#CurrentVersion, #CurrentList, queryRun.pack()];
}

public boolean unpack(container _packedClass)
{
    Version version = RunBase::getVersion(_packedClass);
    boolean ret = true;

    switch (version)
    {
        case #CurrentVersion :
            container packedQuery;
            [version, #CurrentList, packedQuery] = _packedClass;
            if (SysQuery::isPackedOk(packedQuery))
            // ...

Обратите внимание, что конструкция вида

[version, #CurrentList, packedQuery] = _packedClass;

симметрична конструкции

return [#CurrentVersion, #CurrentList, queryRun.pack()];

она позволяет безболезненно отбросить все лишние элементы в конце контейнера _packedClass и взять своё строго с тех позиций, какие получились в вашем pack().
Но локализаторы же хитрее всех, поэтому они считают, что их запакованный queryRun всегда идет последним, и пишут вот что:

public boolean unpack(container packedClass)
{
    Integer     version = conPeek(packedClass,1);
    container   packedQuery = conPeek(packedClass, conLen(packedClass));

Поскольку наш контейнер стал длиннее за счет параметров класса-расширения, то вместо запакованного queryRun локализаторы, разумеется, получают левый контейнер и валятся на нем в ошибку времени выполнения.

[ax_mct]

Цитата:

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

...
Но в случае RAssetProposal следование официальной инструкции приводит к ошибке времени выполнения в расширяемом классе: невозможно инициализировать queryRun из контейнера.
...
Вот как бы вы работали с queryRun в pack/unpack? Обычно это выглядит так:
...

Re: "контейнер стал длиннее"

Спасибо за опыт! Делаю вывод что в топку их инструкцию так любое их обновление unpack может вызвать подобный сценарий ошибки.

Часв два времени сделать свою таблицу и отладить код для хранения своего контейнера.

То есть:
CoC на pack/unpack но без изменений того что кладется и вынимается.
Собственная таблица для хранения своего дополнительного контейнера.

Напрягает что в любом будущем автоматическом накате изменений может быть такая ошибка. Сейчас OK, а скажем через год добавят диалоговый параметр и плохо напишут код в unpack.

Думаю что это самый классический случай когда будущее изменение вендора может сломать приложение без ошибок компиляции.

Кто будет виноват. Мы. Из-за нашего расширения ошибка - да.
Подстава.