Беда с set'ом

[Vasiliusis]

Добрый день! Данный код не отрабатывает...

    set         mySet = new Set(Types::Record);
    ;
    
    mySet.add(CustTable::find('Клиент1'));
    mySet.add(CustTable::find('Клиент2'));
    if (mySet.in(CustTable::find('Клиент1')))
        info(strfmt('%1', mySet.remove(CustTable::find('Клиент1'))));

самое весело, что не отрабатывает именно remove. IF выполняется. Что за мистика такая?

[Stitch_MS]

В ядре 6.3.4000.2855 отрабатывает.

[Vasiliusis]

да, забыл уточнить, ms dax2009

[ax_mct]

Цитата:

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

Добрый день! Данный код не отрабатывает...

    set         mySet = new Set(Types::Record);
    ;
    
    mySet.add(CustTable::find('Клиент1'));
    mySet.add(CustTable::find('Клиент2'));
    if (mySet.in(CustTable::find('Клиент1')))
        info(strfmt('%1', mySet.remove(CustTable::find('Клиент1'))));

самое весело, что не отрабатывает именно remove. IF выполняется. Что за мистика такая?

Что-то останавливает писать такой код. Я бы так не смог. Нутро бы не дало.

Или хранить RecId в Set или использовать Map c ключом RecId и значением типа Record.

[Vasiliusis]

Цитата:

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

Что-то останавливает писать такой код. Я бы так не смог. Нутро бы не дало.

Или хранить RecId в Set или использовать Map c ключом RecId и значением типа Record.

функционалом предусмотрен такой код, почему бы его не написать... делать по-вашему ни в первом ни во втором случае не представляется возможным условиями задачи. сейчас попробую с использованием SetIterator'a сделать, будет громоздко, но лишь бы работало

[Stitch_MS]

Цитата:

It is best practice to use the (SetEnumerator) class instead of the SetIterator class. This avoids problems if you are accessing the set on one tier with an iterator on another tier. Set iterators and the sets over which they iterate must be on the same client/server side. If you use SetIterator and code is marked as Called from, it is possible that the set and the iterator will end up on different tiers, and the code will fail. If you use SetEnumerator, the enumerator is automatically created on the same tier as the set. Also, to move to the next item in a set, you must explicitly call the more and next methods if you are using a set iterator. If you use SetEnumerator, you only have to call moveNext method.

https://msdn.microsoft.com/en-us/lib...titerator.aspx

[Vasiliusis]

Цитата:

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

https://msdn.microsoft.com/en-us/lib...titerator.aspx

в setEnumerator нет метода удаления. С SetIterator другая проблема

буду делать с помощью List и ListIterator, он отработал

[ax_mct]

Цитата:

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

функционалом предусмотрен такой код, почему бы его не написать... делать по-вашему ни в первом ни во втором случае не представляется возможным условиями задачи. сейчас попробую с использованием SetIterator'a сделать, будет громоздко, но лишь бы работало

Чем отличается опытный программист от неопытного? Именно этим: "функционалом предусмотрен такой код, почему бы его не написать?"

SetEnumerator как уже отметили, будет лучше. Так же как и MapEnumerator.

А то что не представляется возможным по условиям задачи использовать другой код - это бред.

Не потому что не работает, а потому дикий код он и в стандарте - дикий.

P.S. List - вот это более натурально. Я лично доверяю Set только RecID. Оно как бы и логично.
P.P.S. Кстати временная таблица в сложных случаях - тоже опция.

[fed]

А что будет, если у вас между первым, вторым и третьим вызовами CustTable::find('Клиент1'), соседний пользователь что-то обновит и всякие modifiedBy, ModifiedDateTime, modifiedTransactionId, recVersion и тд и тп - поменяются ? Какого поведения от системы вы ожидаете в этом случае (особенно если условие myset.in() отрабтает, а дальнейшая попытка что-то удалить обломается в связи с тем что поля у записи в set и в табличном буфере - разные)?

[Vasiliusis]

сделаю через List

[Vasiliusis]

Цитата:

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

А что будет, если у вас между первым, вторым и третьим вызовами CustTable::find('Клиент1'), соседний пользователь что-то обновит и всякие modifiedBy, ModifiedDateTime, modifiedTransactionId, recVersion и тд и тп - поменяются ? Какого поведения от системы вы ожидаете в этом случае (особенно если условие myset.in() отрабтает, а дальнейшая попытка что-то удалить обломается в связи с тем что поля у записи в set и в табличном буфере - разные)?

для этого я буду сравнивать только TableId и RecId

[fed]

Цитата:

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

для этого я буду сравнивать только TableId и RecId

Это в целом - правильная идея, но тогда и List не понадобится. Достаточно будет сделать set из контейнеров с двумя элементами.

[Vasiliusis]

Цитата:

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

Это в целом - правильная идея, но тогда и List не понадобится. Достаточно будет сделать set из контейнеров с двумя элементами.

согласен

[ax_mct]

Цитата:

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

согласен

Я бы использовал Set только для набора примитивных типов как RecId.
Что-то там было, а что уже и не помню. В системном коде более принятый вариант все же Map(RecId, Record). Если нужен составный ключ то просто делайте уникальную строку TableId&&RecId. Тоже общий подход.

И подумайте нужно ли вам удаление. Возможно несколько коллекций будет лучше, то есть результат - в отдельный Map или в Set если RecId или строка как ключ. Дорогое это удаление. Уверен можно без него обойтись.

[dech]

Если в контексте подразумевается конкретная таблица, то TableId не нужен. Саму запись хранить в коллекции - дурной тон (Record***List - исключение из правил). Для Set/Map/List лучше и быстрее работать с RecId. Если вам нужно работать непосредственно с некоторым набором записей, сделайте CustTable временной таблицей. Как вариант еще можно RecordInsertList рассмотреть.

[Stitch_MS]

Цитата:

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

Как вариант еще можно RecordInsertList рассмотреть.

Может лучше RecordSortedList?

[Товарищ ♂uatr]

Цитата:

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

Добрый день! Данный код не отрабатывает...

На ядрах:
4.0.2503...
5.0.1500...
6.3.164...
Код выполняется корректно, кол-во элементов сета уменьшается с 2 до 1.