Dynamics AX: Map Object Sorting - a real issue

[Blog bot]

Источник: http://dynamics-ax.blogspot.com/2008...eal-issue.html
==============
Alright,

So I am sure everyone has used Map objects in writing X++ code before. Map's are part of Collection classes that exist inside Dynamics AX.

Well one of the strangest things about this Collection class, is that it's lack or sorting methods. It does not have any. You can't sort a Map object by values or Keys, and if you can, it's buried so deep that no one has wrote about it or found it.

What kind of sorting I did see today, with my partner in crime Derek Pate, was based on the Type for the Key value of the map.

For example, say you have:

3,4,5,6,7,8,10,12,14,16

as values. Now if these values are integer based from the source your pulling from or you convert to, and you take and insert these values as listed with some form of while loopping on the object that carried these values for you, sorted in the above way, you would expect these to appear in the object your inserting too, in that same sorted order. Right?

Wrong!

If you are trying to insert the above values, of type integer, into a Map of Types::String, Types::String you will end up with the following sorted values for that Map's value elements:

"10","12","14","16","3","4","5","6","7","8"

So even though there is not a known / published sorting method or built-in function for sorting a Map, it tries to automatically sort the values for you based on type, even though you inserted those values into the map object the order desired.

This is one of those strange things that exists, that should not actually. The ability to sort, and sorting to exist for the developer at hand. Not a guessed sorting order, based on type.

Maybe an improvement suggestion? Have you seen this before? Do you have a sorting method you like to use for Map Object Values? Let me know here... and check back soon!




"Visit the Dynamics AX Community Page today!"




==============
Источник: http://dynamics-ax.blogspot.com/2008...eal-issue.html

[mazzy]

- "Вжик", сказала японская бензопила
- "Э-э-э...", сказали русские мужики"

Цитата:

Сообщение от Blog bot

Maybe an improvement suggestion?

Предложения есть: не заниматься фигней и не совать целочисленные коды в map.
Юзать нормальные номерные серии с префиксами, вместо целочисленных счетчиков.
http://axapta.mazzy.ru/lib/numbersequence/
http://axapta.mazzy.ru/lib/adjustment/

[TasmanianDevil]

Сергей, а причем здесь номерные серии ?
В исходном сообщении ни слова о Number Sequences ...

Брать Integer, конвертить в String и ожидать одинаковой сортировки
Этот чудаковатый джентельмен (совсем другой эпитет напрашивается) просто совершенно не имеет представления о разных, из-за различий бинарного представления, результатах сортировки визуально похожих, но имеющих разный тип, данных.

Tech Architector из Алабамы, блин ...
Как-то давненько я двигал мысль о том, что люди , занимающие позиции верхних уровней IT-сферы и без некоторого багажа опыта с нижних уровней, очень часто являют собой мыльный пузырь с точки зрения профессионализма - собственно что и наблюдаем ...

P.S. В Алабаму - ни ногой !
P.P.S. Боту - минус. Таскает всякую гадость, железяка глупая ...

[Gustav]

Мне это сообщение напомнило о том (после того, как я накидал джобик), что можно случайно забыть, какой тип у ключа и у значения Map и без проблем засунуть целочисленные значения в строковые и наоборот - и, соответственно, получить "неожиданную" сортировку. Чего не скажешь, например, о Set, у которого контроль на входе более жесткий.

А джобик прилагаю (раз уж накидал)

static void Job92(Args _args)
{
    Map map = new Map(Types::String, Types::String);
    //Map map = new Map(Types::Integer, Types::Integer);

    Set setStr = new Set(Types::String);
    Set setInt = new Set(Types::Integer);
    ;

    //3,4,5,6,7,8,10,12,14,16

    map.insert(3,3);
    map.insert(4,4);
    map.insert(12,12);
    map.insert(14,14);
    map.insert(16,16);
    map.insert(5,5);
    map.insert(6,6);
    map.insert(7,7);
    map.insert(8,8);
    map.insert(10,10);

    setStr.add('7');
    setStr.add('8');
    setStr.add('10');
    setStr.add('3');
    setStr.add('4');
    setStr.add('5');
    setStr.add('6');
    setStr.add('12');
    setStr.add('14');
    setStr.add('16');

    setInt.add(14);
    setInt.add(16);
    setInt.add(10);
    setInt.add(12);
    setInt.add(6);
    setInt.add(7);
    setInt.add(8);
    setInt.add(3);
    setInt.add(4);
    setInt.add(5);

    info(map.toString());

    info(setStr.toString());
    info(setInt.toString());
}

P.S. Задействовать номерную серию для генерации строковых ключей в Map, наверное, можно, но я обычно обхожусь походным текстовым счетчиком типа:

key ='N'+subStr(int2str(1000000+i),2,6); // N000001

или просто равнодлинными "телефонными номерами", т.е. с добавлением заведомо большого числа:

key =1000000+i; // 1000001

[mazzy]

Цитата:

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

Сергей, а причем здесь номерные серии ?

Генерировать строку правильной длины с правильными префиксами.

Цитата:

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

P.S. Задействовать номерную серию для генерации строковых ключей в Map, наверное, можно, но я обычно обхожусь походным текстовым счетчиком типа:

key ='N'+subStr(int2str(1000000+i),2,6); // N000001

Во-во. Хардкор какой-то
Лучше уж номерными сериями.

[Lemming]

Цитата:

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

Предложения есть: не заниматься фигней и не совать целочисленные коды в map.
Юзать нормальные номерные серии с префиксами, вместо целочисленных счетчиков.

Хмм...а не скажется ли это на производительности!?! Выделять номера из номерной серии, например при сборке map-a который впоследствии будет использоваться в отчете. ИМХО, "из пушки по воробьям". Да и вообще, map-ы не так просты в поддержки и отладке кода, так что, кмк, лучше просто внимательно относиться к их использованию и не ставить такие эксперименты с автоматическим приведением типов.

p.s. Кстати, мне этот пост оказался полезным, я и не знал, что такой фокус можно провернуть и натворить делов, так что "железяка глупая" правильно все импортировала

[gl00mie]

Цитата:

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

Хмм...а не скажется ли это на производительности!?! Выделять номера из номерной серии, например при сборке map-a который впоследствии будет использоваться в отчете. ИМХО, "из пушки по воробьям".

Нии... не надо ничего ниоткуда выделать, можно просто использовать механизм форматирования идентификаторов по шаблону из класса номерных серий: скормить статическому методу NumberSeq::numInsertFormat() шаблон и счетчик - и получить на выходе «красивый» идентификатор. Никаких предварительных настроек, никаких дополнительных обращений к БД, ничего этого, конечно же, для простого заполнения Map'а не нужно.

Цитата:

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

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

Я лично вообще слабо представляю, как можно напутать с типом ключа Map'а. Ведь обычно они заполняются там же, где и создаются, максимум в разных методах одного класса или иерархии классов

[Lemming]

Цитата:

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

Нии... не надо ничего ниоткуда выделать, можно просто использовать механизм форматирования идентификаторов по шаблону из класса номерных серий: скормить статическому методу NumberSeq::numInsertFormat() шаблон и счетчик - и получить на выходе «красивый» идентификатор. Никаких предварительных настроек, никаких дополнительных обращений к БД, ничего этого, конечно же, для простого заполнения Map'а не нужно.

Ясно, спасибо за пояснение. Может и пригодится в будущем.

Цитата:

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

Я лично вообще слабо представляю, как можно напутать с типом ключа Map'а.

Согласен, однако потенциальная возможность оказывается существует.