Поррассуждаем? Как лучше работать с парой связанных значений в классах? (например, nullable)

[mazzy]

Сразу скажу, я уже реализовал "как проще".
Но хотелось бы поррасуждать - вдруг есть какое-то более изящное решение?

И давайте для определенности будем говорить о:
1. ax2009 и ax2012.
2. о какой-нибудь обработке runBaseBatch - чтобы и у пользователя спрашивать, и между клиентом-сервером значение передавать, и сериализация была, и нужно было бы хранить в базе


Итак, задача: при определенном условии, у пользователя надо спросить значение чего-то. все значения имеют смысл. Но если условие не выполняется, то значений нет.

Примеры:

• если для записи считают checksum, то поле checksum хранит контрольную сумму (любое значение имеет смысл)
• если для данного клиента включен контроль кредитного лимита, то спросить и хранить этот кредитный лимит
• для данной поставки нужен контроль даты поставки, то спросить и хранить дату доставки. при этом не введенное значение (datenull()) имеет смысл. Например, контроль включен, у клиента спросили, но ему не важно.
• если по договору у клиента надо спросить подтверждение, то хранить Да/Нет, введенное пользователем.
• работать с традиционным null-значением из внешней неаксаптовской базы
• и т.п.

другими словами, в алгоритмах используется пара значений - tuple(есть ли значение, значение)

Задача сводится к "работа с nullable значениями"
с точки зрения программирования, очень похоже на работу с классом.

myClass = new MyClass();
if(myClass)
{
   myValue = myClass.parmMyValue();
   // делаем что-то со значением
}
else
{
   // класс не создался, нет значений
}

Думаю, что формулировка понятна.

===================================
Какие манипуляции хотелось бы делать с подобными значениями в Аксапте:

1. хранить в базе
2. передавать как параметр метода
3. спрашивать значения у пользователя на формах и в программных диалогах
4. передавать между клиентом и сервером (pack/unpack)
5. сериализация = записывать/считывать подобные значения во внешние хранилища (XML, текстовый файл и т.п.)
6. что-то еще?

==================================
Какие варианты реализации есть, на мой взгляд:

1. выделить одно из значений как null. например, использовать не перечисление NoYes, а перечисление из 3х значений - NoYesNull
2. объявлять/хранить как два независимые поля (две независимые переменные)
3. объявлять как контейнер
4. создать класс (что-то вроде tuple)
5. временная таблица?
6. что-то еще?

может что добавите пока буду создавать следующее сообщение с плюсами и минусами вариантов реализации.

заранее спасибо за конструктивное обсуждение.

[mazzy]

итак, плюсы/минусы реализаций:

1. выделить одно из значений как null. например, использовать не перечисление NoYes, а перечисление из 3х значений - NoYesNull
1.1. плюсы:
1.1.1. очень компактно и просто,
1.1.2. легко сериализируется,
1.1.3. легко встраивается в pack/unpack
1.1.4. полный контроль типов со стороны IDE

1.2. минусы:
1.2.1. не всегда это можно сделать. см. пример с хранением контрольной суммы.
1.2.2. нужны функции-преобразователи, чтобы преобразовать к интерфейсному типу. для данного примера: чтобы спросить у пользователя привычную галочку, нужен преобразователь NoYesNull <-> NoYes. Причем Null значение преобрауется в control.enabled(false). или в control.visible(false)
1.2.3. обработка Null-значения будет раскидана по всему коду

2. объявлять/хранить как два независимые поля (две независимые переменные)
2.1.плюсы:
2.1.2. легко сериализируется,
2.1.3. легко встраивается в pack/unpack
2.1.4. полный контроль типов со стороны IDE

2.2.минусы:
2.2.1. громоздко - передавать эту пару в методы - забибикаешься.

3. объявлять как контейнер
3.1. плюсы:
3.1.1. очень компактно и просто,
3.1.2. легко сериализируется,
3.1.3. легко встраивается в pack/unpack

3.2. минусы:
3.2.1. никакого контроля типов.
3.2.2. все ошибки в runtime

3. создать класс (что-то вроде tuple)
3.1. плюсы
3.1.1. контроль типов
3.1.2. нормально сериализуется - см. AIF-примитивы
3.1.3. удобно отлаживать - достаточно переопределить метод toString

3.2. минусы
3.2.1. ни фига не компактно и не просто - очень громоздко
3.2.2. поседеешь пока встроишь в pack/unpck
3.2.3. очень неудобно отображать эти классы в поля формы или диалога

4. временная таблица?
4.1. плюсы
4.1.1. контроль типов
4.1.2. нормально сериализуется
4.1.3. легко работать с набором значений (не одна запись, а несколько во временной таблице)

4.2. минусы
4.2.1. неудобно отлаживать
4.2.2. неудобно передавать значения
4.2.3. неудобно создавать подобные пары - слишком много телодвижений надо сделать
3.2.3. очень неудобно отображать эти классы в поля формы или диалога


буду рад вашим замечаниями и дополнениям.

[skuull]

Цитата:

1. выделить одно из значений как null. например, использовать не перечисление NoYes, а перечисление из 3х значений - NoYesNull

Уже есть тип UnknownNoYes. И похожие танцы по всей Ах

Цитата:

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

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

[mazzy]

Цитата:

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

Уже есть тип UnknownNoYes. И похожие танцы по всей Ах

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

Цитата:

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

А что из вышеперечисленного удобно отображать?

да, костыли лепить придется.

но соображения такие:
= отображение - это семейство методов/классов.
= поэтому удобнее отображать там, где пара связанных объектов передается как она сущность.
= но при этом способ должен быть таким, чтобы не насиловать среду разработки.

например, объект класса - в текущей версии удобно передавать как параметр в методы, но неудобно встраивать в pack/unpack.

[makbeth]

Я бы выбрал гибрид способа 2 и... 3, который создание класса (нумерация немного того). В базе храним парой разных полей (альтернатив здесь вообще говоря особо и нет). В всех остальных местах - классом. В RunBase и прочих подобных сценариях можно использовать как класс, так и пару переменных. Там с отдельным классом неудобство только одно - распаковку приходится делать через промежуточную переменную - контейнер. И кстати, вот неявно цепляется и "контейнерный" способ. При передаче можно задействовать и его, как только понадобится что-то более серьезное - проверка, сериализация и т.п. - быстренько его Tuple::create(packedTuple) и работаем с удобным классом.

В общем, если сложить плюсы и сократить минусы - то минусов как бы и не остается.

[gl00mie]

Цитата:

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

Примеры:

• если для записи считают checksum, то поле checksum хранит контрольную сумму (любое значение имеет смысл)
• если для данного клиента включен контроль кредитного лимита, то спросить и хранить этот кредитный лимит
• для данной поставки нужен контроль даты поставки, то спросить и хранить дату доставки. при этом не введенное значение (datenull()) имеет смысл. Например, контроль включен, у клиента спросили, но ему не важно.
• если по договору у клиента надо спросить подтверждение, то хранить Да/Нет, введенное пользователем.

Для checksum хорошее null-значение - 0. Я лично ни за что не стал бы рассматривать 0 как корректное значение рассчитанной контрольной суммы. Для кредитного лимита может быть null-значение 0, как в стандарте. Для дат null-значением может быть maxDate(), раз уж значение dateNull() является допустимым. По поводу UnknownNoYes уже писали

Цитата:

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

• работать с традиционным null-значением из внешней неаксаптовской базы
• и т.п.

Работа из внешней системы предполагает, как мне кажется, в первую очередь возможность нормально читать/писать такие значения в поля таблиц. Это значит, что те же контейнеры уже не подходят, поскольку нарушают 1-ю нормальную форму и вообще очень неудобны для чтения/записи из внешних систем. Так что остается либо null-значение, либо доп. поле.

Цитата:

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

другими словами, в алгоритмах используется пара значений - tuple(есть ли значение, значение). Какие манипуляции хотелось бы делать с подобными значениями в Аксапте:

1. хранить в базе
2. передавать как параметр метода
3. спрашивать значения у пользователя на формах и в программных диалогах
4. передавать между клиентом и сервером (pack/unpack)
5. сериализация = записывать/считывать подобные значения во внешние хранилища (XML, текстовый файл и т.п.)
6. что-то еще?

Что-то еще в хотелках/требованиях - чтобы код работы с этими... кортежами не был громоздким Иначе почему громоздкость фигурирует в оценке каждого варианта?

Цитата:

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

итак, плюсы/минусы реализаций:
4. временная таблица?
4.1. плюсы
4.1.1. контроль типов
4.1.2. нормально сериализуется
4.1.3. легко работать с набором значений (не одна запись, а несколько во временной таблице)

Стоп-стоп, какие еще несколько записей? Изначально было вот что заявлено:

Цитата:

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

другими словами, в алгоритмах используется пара значений - tuple(есть ли значение, значение)

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

Цитата:

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

4.2. минусы
4.2.1. неудобно отлаживать
4.2.2. неудобно передавать значения
4.2.3. неудобно создавать подобные пары - слишком много телодвижений надо сделать
3.2.3. очень неудобно отображать эти классы в поля формы или диалога

Непонятно, откуда взялись неудобства Я бы лично рассматривал буфер временной таблицы именно как tuple(есть ли значение, значение), реализованный в виде двух табличных полей, вообще на время забыв о том, что во временные таблицы можно вставлять записи. Что мы получаем тогда с учетом изначальных требований?

• хранить в базе - удобно, как два отдельных поля, чтобы не нарушать 1-ю нормальную форму
• передавать как параметр метода - удобно, как один параметр табличного типа;
• спрашивать значения у пользователя на формах и в программных диалогах - относительно удобно, может потребоваться некий мини-фреймворк для инкапсуляции рутины, связанной с чтением/записью признака наличия значения;
• передавать между клиентом и сервером (pack/unpack) - удобно, пиши себе [buf.HasValue, buf.Value] - и не важно, читаешь ты буфер времянки в pack() или пишешь в unpack(), во всяком случае, так же удобно, как использовать две отдельных переменных, и куда удобнее использования класса для tuple
• сериализация = записывать/считывать подобные значения во внешние хранилища (XML, текстовый файл и т.п.) - удобно, аналогично хранению в базе

Стоит обратить внимание на реализацию метода SysQuery::inRange() - там используется времянка с отдельным полем под каждый базовый значимый тип. Я бы, возможно, использовал схожий подход: сделал бы отдельную времянку для tuple каждого базового типа и использовал бы соотв. буфер в тех местах, где нужно работать с nullable-значением этого типа. Как уже отмечалось, контроль компилятора - не хуже, чем с обычной переменной базового типа, передача в методы, сериализация - всё есть, отлаживать удобно (развернуть в отладчике, в окне Variables/Watch буфер и посмотреть значения отдельных полей). При всем при этом на времянке можно реализовать вспомогательные методы под часто используемые сценарии, тот же toString() какой-нить - не для отладчика, а для вывода значений в сообщениях. Т.е. получаются плюсы использования класса без минусов возни с инициализацией переменной класса и доступа к его свойствам, особенно в pack/unpack.

[Владимир Максимов]

Хм.. Вроде как и есть что сказать по теме, но, вроде бы и так уже все сказано. Только систематизировано несколько по другому, из-за чего и "едет крыша". Как мне кажется, критически важным является ответ на первую "хотелку".

Цитата:

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

Какие манипуляции хотелось бы делать с подобными значениями в Аксапте:

• хранить в базе

Возможные варианты:

1. Выделить (интерпретировать) одно из значений как null
   • Выделенное значение отображается как пустое значение в диалоге с пользователем (255 для Base Enum, num2char(160) для String, 0.0001 для AmountCur, 0.1 для CheckBox и т.д и т.п.)
   • Выделенное значение не может быть отображено "как есть" в диалоге с пользователем. Требуется "перевод" (maxDate() для Date, maxInt() для int и т.п.)
2. Добавить еще один признак (поле), показывающий, что "основное" значение надо интерпретировать как null. Одно дополнительное поле может "обслуживать" несколько "основных" полей.
   • Отдельный признак имеет самостоятельное значение и отдельно отображается в диалоге с пользователем. Например, признак "Контролировать кредитный лимит" определяет учитывать ли значения полей "Сумма лимита" и "Дата установки контроля"
   • Отдельный признак является "системным" (служебным) полем и для пользователя недоступен. Например, признак значения NULL для контрольной суммы (Хотя... Впрочем, за не именеем более наглядного примера)

Дальнейшая реализация будет существенным образом зависеть от выбранного способа хранения значения NULL в базе данных. Ну, с первыми 3 вариантами дальнейшая работа понятна. Обычный набор переменных. Некоторые сложности может доставить перекодировка из maxdate() в пустое значение для отображения, но не думаю, что эта такая уж большая проблема.

Проблемным является последний вариант, когда дополнительный признак является служебным полем, недоступным для прямого просмотра/изменения пользователем. Вот здесь на первое место выступает вторая ключевая "хотелка"

Цитата:

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

• спрашивать значения у пользователя на формах и в программных диалогах

Каким образом будет построен интерфейс с пользователем, чтобы пользователь мог понять, где значение будет интерпретировано как null, а где - как указанное значение? Пусть даже пользователь и "не трогал" этого значения. Или "потрогал", но вернул назад

Вообще-то, мне приходит в голову только один вариант на подобный случай. Это когда речь идет о полях, которые пользователь изменить не может. Максимум посмотреть. Та же контрольная сумма. Но это значит, что речь идет о неких расчетных значениях, которые, очевидно, зависят от других реквизитов. Так может, можно эти самые "другие реквизиты" и использовать как признак значения NULL?


Если же рассматривать вопрос БЕЗ учета этих двух основных "хотелок", например, как передача неких параметров при расчетах, то можно рассмотреть еще парочку вариантов.

• Очень ограниченно можно использовать (prmIsDefault() == 1) как признак того, что параметр передан не был. Т.е. интерпретировать это как передачу null. Правда, для pack/unpack это не пригодно, но ведь интерфейс с пользователем нас не интересует
• В среде Axapta значение NULL физически может быть сохранено в переменной типа ComVariant. В принципе, тот же класс, но чуть проще

    COMVariant comVariant;
    ;
    comVariant = new ComVariant(COMVariantInOut::In_out, ComVariantType::VT_BOOL);
    info(comVariant.toString());
    info(strFmt('%1',comVariant.variantType()));

    comVariant.variantType(ComVariantType::VT_NULL);
    info(comVariant.toString());
    info(strFmt('%1',comVariant.variantType()));

[mazzy]

Цитата:

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

Для checksum хорошее null-значение - 0.

в общем, одно из значений трактовать как null...

Цитата:

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

Что-то еще в хотелках/требованиях - чтобы код работы с этими... кортежами не был громоздким Иначе почему громоздкость фигурирует в оценке каждого варианта?

хз. лично мне просто лениво писать громоздкие конструкции. из-за этого я, например, не люблю использовать struct в аксапте.

но может быть сформулировать по-другому хотелки/требования?
я бы с удовольствием послушал.

Цитата:

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

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

да, согласен.

в общем, временная таблица? надо подумать. надо попробовать. я этот вариант всегда рассматривал как чисто теоретический.

[mazzy]

Цитата:

Сообщение от Владимир Максимов

Возможные варианты:

угу. а еще есть? а можно всех посмотреть?

Цитата:

Сообщение от Владимир Максимов

Каким образом будет построен интерфейс с пользователем, чтобы пользователь мог понять, где значение будет интерпретировано как null, а где - как указанное значение? Пусть даже пользователь и "не трогал" этого значения. Или "потрогал", но вернул назад

Вот!
Для примера возьмем MS SQL и Аксапту 2012, которые умеют отображать null значение, полученное из базы. там в поле отображается специальное значение null, а поле становится недоступным для редактирования.

В аксапте 2012 со специальным значением напряжно. Но, думаю, что надо делать поле недоступным для пользователя.

Но, опять же, хотелось бы выслушать варианты.

Цитата:

Сообщение от Владимир Максимов

Вообще-то, мне приходит в голову только один вариант на подобный случай. Это когда речь идет о полях, которые пользователь изменить не может. Максимум посмотреть. Та же контрольная сумма. Но это значит, что речь идет о неких расчетных значениях, которые, очевидно, зависят от других реквизитов. Так может, можно эти самые "другие реквизиты" и использовать как признак значения NULL?

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

"если для данного клиента включен контроль кредитного лимита, то спросить и хранить этот кредитный лимит"

Цитата:

Сообщение от Владимир Максимов

Очень ограниченно можно использовать (prmIsDefault() == 1) как признак того, что параметр передан не был. Т.е. интерпретировать это как передачу null.

не совсем.
чтобы срабатывал prmIsDefault в вызывающем классе параметр не должен быть указан.

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

Цитата:

Сообщение от Владимир Максимов

В среде Axapta значение NULL физически может быть сохранено в переменной типа ComVariant.

Ну... Насколько я помню он не pack/unpack-совместимый.
И как он передается между клиентом и сервером?

[Владимир Максимов]

Цитата:

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

угу. а еще есть? а можно всех посмотреть?

Варианты хранения доп.признака в базе данных? Так вроде все перечислил. Ну, если не считать собственно поддержку NULL для поля. Или интересует вариант технической реализации? Так это у кого на что фантазии хватит. Например, для хранения признака создавать не по отдельному полю для каждого поля с возможным NULL, а одно общее поле, где хранить битовую маску...

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

Например, заменить CheckBox на ComboBox с 3 вариантами выбора (All / Yes / No). Для текста (кода справочника) создать специальный элемент справочника с пустым кодом.

Цитата:

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

Вот!
Для примера возьмем MS SQL и Аксапту 2012, которые умеют отображать null значение, полученное из базы. там в поле отображается специальное значение null, а поле становится недоступным для редактирования.

Как мне кажется, это не правильное решение разработчиков. Ведь получается, что если поле приняло значение null, то пользователь его не может изменить напрямую. Чтобы пользователь смог изменить это поле, его значение должно быть программно установлено в пустое значение. Фактически, создается доп.поле, содержащее признак необходимости изменить основное поле. Что возвращает к реализации с двумя полями.

Цитата:

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

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

"если для данного клиента включен контроль кредитного лимита, то спросить и хранить этот кредитный лимит"

Опять я не в курсе "новых веяний" в Ax2012, но в младших версиях Axapta все ключевые реквизиты, необходимые для расчета копировались в подчиненные и связанные таблицы. Т.е. находится за тысячу километров таблиц он не должен. Это ошибка проектирования (хотя и нарушает принципы нормализации)

В данном примере, где будет хранится сумма кредитного лимита? Ну, предположительно, либо в таблице клиента, либо в таблице договоров. В обоих случаях признак контроля кредитного лимита должен быть в той же таблице.

Цитата:

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

не совсем.
чтобы срабатывал prmIsDefault в вызывающем классе параметр не должен быть указан.

Угу. Так я так и написал "очень ограниченно" Т.е. в очень специфических ситуациях.

------------------

Если просто "перечислять варианты", то вот еще парочка идей

1. Объект Map из одного элемента: ключ - признак NULL, значение - значение
2. Объект Struct из одной "строки". Одно "поле" - признак NULL, другое - значение. Если добавить 3 поле-идентификатор, то можно в один объект Struct собрать все переменные для обработки, сделав несколько "строк". Аналог временной таблицы
3. Объект Set или List из одного элемента. В случае, если значение эквивалентно NULL, то не создавать (или удалять) элемент. Нет элементов - значение NULL

Эти объекты позволяют сделать частичный контроль типов (правда, только на уровне базовых типов), а также имеют встроенные методы pack/create, что упрощает их передачу в pack/unpack