Объясните странное поведение enum'ов

[Deep Dreamer]

Есть стандартный пример функции enum2str:

PHP код:

static void Job7(Args _args)
{
      LedgerJournalACType     p;
      p = LedgerJournalACType::Ledger;
      info( enum2str(p) );
} 


Есть попытка применить эту функцию:

PHP код:

static void Job6(Args _args)
{
    LedgerJournalTrans  ljt;
    set                 s=new set(types::Enum);
    setiterator         si;
    LedgerJournalACType tmp;

    while select firstonly ljt
    {
        s.add(ljt.OffsetAccountType);
    }

    si = new setiterator(s);
    while(si.more())
    {
        tmp = si.value();
        info(enum2str(tmp));
        si.next();
    }
} 


Вызов

PHP код:

 info(enum2str(tmp)); 


приводит к ошибке времени выполнения. Почему? Причём в debugger'е значение tmp вполне корректно

[mazzy]

непонятно. похоже опять что-то с преобразованием типов в AnyType...

я хотел про другое сказать...
ваш код чудовищно неоптимален.
особенно в 3хуровневной архитектуре.

лучше написать что-то в виде

PHP код:

static void Job6(Args _args)
{
    LedgerJournalTrans  ljt;
    LedgerJournalACType tmp;

    while select ljt
        group by OffsetAccountType 
    {
        info(enum2str(ljt.OffsetAccountType));
    }
} 


В чем разница?
Запрос выполняется на сервере, а не на клиенте.
Количество записей, которое передается на клиента на несколько порядков меньше.

Следовательно меньше трафик.
Следовательно меньше требования к клиенту.
Следовательно меньше блокировок.
Следовательно общая производительность повышается.

[Maxim Gorbunov]

Как говорится, Сократ мне друг, но истина дороже.

1. Вообще-то, запрос всегда будет выполняться на сервере БД, так как он является запросом к БД Результаты всегда будут пересылаться на клиента, так как Job'ы всегда выполняются на клиенте.

2. Следовательно траффик не при чем, требования к клиенту вообще не при делах (Сергей, правда, имел ввиду требования к каналу связи ). Блокировки если были, то останутся. Общая производительность системы в этом случае не изменится (как средняя температура по больнице).

3. Записей в варианте mazzy будет возвращено больше, хотя бы потому, что его запрос просто подразумевает возвращение большего количества записей (у DeepDreamer их будет всего одна, так как он ввернул firstonly в свой запрос).

А по вопросу DeepDreamer могу только сказать, что это очередной заскок компилятора, который, впрочем, связан с очевидным недостатком синтаксиса X++. Дело в том, что функция enum2str() должна догадаться о том, какой тип имеет enum (он не передается как аргумент) исходя из синтаксиса метода. Видимо получение значения enum'а из anytype очень сильно путает компилятор. Сделайте так:

PHP код:

// tmp = si.value();
tmp = any2int(si.value()); 


В таком случае компилятор разберется.

[mazzy]

Цитата:

Изначально опубликовано Maxim Gorbunov
3. Записей в варианте mazzy будет возвращено больше, хотя бы потому, что его запрос просто подразумевает возвращение большего количества записей (у DeepDreamer их будет всего одна, так как он ввернул firstonly в свой запрос).

Использование firstonly - явная ошибка у Deep Dreamer.
Смысл с этим модификатором полностью теряется.
Задача (насколько я понимаю): получить список типов коррсчетов, которые используются в журналах.

Да, запрос будет выполняться на сервере.
Но в первом случае, ВСЯ логика обработки выполняется на клиенте.
Во втором случае почти вся логика выполняется на сервере.

Спасибо за решение.

[Deep Dreamer]

Функция вызывается с параметром tmp типа LedgerJournalACType, т.е. enum. Но после присвоения anytype получается, что передаётся туда совсем не enum... Это как?

Re:

Цитата:

ваш код чудовищно неоптимален.

Согласен на 100%! Такой код получился путём удаления всего, что не относится к делу в совсем другом методе. И job вышел по принципу "абы F5 нажать и побыстрее посмотреть что получится". Тем не менее спасибо за ликбез Всегда полезно.

[Maxim Gorbunov]

Цитата:

Изначально опубликовано Deep Dreamer
Функция вызывается с параметром tmp типа LedgerJournalACType, т.е. enum.

Опять же, могу только предполагать. Видимо, присвоение вида enum <- anytype заставляет компилятор терять тип enum'а.

2mazzy: Да, вероятно задача именно так стоит. Из того, что написал вначале DeepDreamer я задачи не понял: рассматривал исключительно как код, не имеющий особого смысла

2DeepDreamer: В варианте, предложенном mazzy, group by играет ту же роль, что и DISTINCT в TSQL. Используйте такой подход. Во избежание недопонимания замечу еще раз, что нагрузка в этом случае переносится на сервер БД, а не на сервер приложений, что, на самом деле, еще лучше (согласно Best Practice).

[AndyD]

Раскопал этот старый тред и показалось любопытным - в чем проблема?

В результате разбора полетов выяснил вот что:
Собственно, ошибка возникает на
tmp = si.value();
Причем, причина не в anytype, а в том, как SetIterator возвращает значение. Любой enum, помимо самого значения, содержит так же тип, к которому он принадлежит. Так вот, SetIterator возвращает значение с типом 65237 (0xFED5). При присвоении енуму с определенным типом (в данном случае LedgerJournalACType) и происходит ошибка конвертации.

Вариантов лечения этой проблемы несколько.
Первый предложил Maxim Gorbunov - преобразовывать полученное значение в целое, а затем уже его присваивать енуму.
Второй - использовать в Set'е целочисленное значение (Types::Integer). В этом случае перед вызовом Add() надо будет преобразовать сохраняемый енум в целое. При считывании преобразований делать не надо - конвертация произойдет автоматически
Третий - использовать вместо SetIterator - SetEnumerator. Енумератор возвращает значение как целое и дополнительных преобразований делать не надо.

Из всего этого следует вот что: внутри set'а не делается различия между разными типами енумов. Например, если в Set добавить ABC::B и ABCModel::Value (оба имеют одинаковое enumValue=2), то получить из него можно только это самое значение (2) - без привязки к типу. Причем, значение будет единственное

Все это также относится и к Map'у. Единственное отличие - MapIterator.key() (а так же MapIterator.value()) возвращает целочисленное значение.