Комбинированные типы данных

Да простят меня боги java runtime и апостолы maven и gradle )
Но по работе я часто доказываю что свет клином на 1С не сошелся и все можно откинуть в сторону, кроме одного, это комбинированные типы данных. Например когда одно поле является одновременно и строкой и сущностью и числом, в зависимости от каких либо условий.
У Марио Дэвида есть расширение soft references.
На его основе можно реализовать данный механизм с использованием напильника.
У меня такой вопрос, планируется ли в платформе данный функционал или нет. Если да, то когда?
Если нет то, мне он необходим и буду делать сам, на основе кода Марио.
Но тут тоже, есть вопрос. Такой аддон нужен сообществу или нет.

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

PS Марио попробую найти и спросить разрешение на форк.

Здравствуйте,

Если у вас задача не только о ссылках, то возможно стоит взять за основу EmbeddableEntity.

Адд-он Mario распространяется под лицензией Apache 2, вы можете свободно его форкать и даже включать в свои закрытые проекты без дополнительного на то разрешения.

1 симпатия

Спасибо за подсказку, поэкспериментирую с ним.

А про лицензию, каюсь я даже не смотрел )

Вообще, насколько понимаю, и правда было бы интересно видеть стандартную реализацию EmbaddedCustomField*.
Насколько могу судить только за последние месяца 4 на русскоязычный форум обращались минимум три разработчика, решающие подобную задачу.
Думаю, на самом деле людей больше и все по своему изобретают велосипед.
Если более конкретно:

  1. Стандартная Embadded-сущность, поддерживающая soft-ference, enum-reference, datatype-value
  2. Ui-компоненты для формирования лукапов, полей редактирования, отображения полей

*компонент предоставляет работу исключительно с сущностями. Выше описана так же задача работы с различными стандартыми дататипами

3 симпатии

Пока что отошел в сторону и провожу эксперименты с кастомным типом данных
https://doc.cuba-platform.com/manual-6.10/datatype_custom_example.html
В теории а не заляпать тип Object и хранить в нем сущность (EmbeddableEntity) с геттерами указывающий на тип данных и откуда и как их брать. Маршал поможет это все сохранить в текстовое поле. Остается небольшая проблема с полями, как грузить несколько видов сущностей, вот тут наверное дальше пойдет кастомный датасет. Но сначала теорию желательно подтвердить практикой )

Вообщем пробую, экспериментирую.

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

Пример проекта на гитхабе

Оказалось достаточно создать свой тип данных и класс контейнер в который все складывать… Ну кому интересно в коде все видно (PS код самого контейнера ужасен, я знаю - т.к. я лентяй и сгенерил скриптом а потом подправил руками).

Поддерживаемые коллекции данных

  • Byte
  • Short
  • Integer
  • Long
  • Float
  • Double
  • Char
  • String
  • Boolean
  • Entity

Внезапно нашлось еще одно очень полезное применение, это мягкие ссылки на сущности типа One-to-Many.
Ведь нам формально никто не запрещает наполнить коллекцию сущностями а потом заполнить им датасет :wink:

А еще тем кто использует postgres, тем jsonb даст много доп плючшек )

Вообщем, кому интересно заберайте, только не забудьте прописать полю сущности конвертера

@Convert(converter = CompositeDatatypeConverter.class)

(Так и не победил как сделать так, чтобы студия сама прописывала аннотацию, если кто подскажет буду очень благодарен)

Следующим этапом буду делать наследника PickerField и экран для работы с типом данных, пока что только кодом.

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

  • Да продолжать.
  • Этого достаточно.
  • Все это никому не нужно!

0 голосов

Тоже похожий подход использовал, только в бд разделял типы по колонкам для последующей возможности индексации* (а так же приема в ‘свободной/человекочитаемой’ форме).

С сущностями, на мой взгляд, необходим другой подход - много места будут занимать, да и хранение snapshot’а сущности (если того не требует Ваша задача) не очень полезная вещь, все равно перезагружать.

*упомянутый выше jsonb, насколько помню, решает проблему

Используется не снепшот, а текстовая ссылка - Марио Дэвид подсказал как сделать ).
Вид в бд

“ofEntity”:[“compositedatatype$Personal-9af4216a-f92d-b1a8-c935-1645fe805bbe”,“compositedatatype$Driver-4a1ad021-9b66-9ed5-0a2e-4424786d0912”],

А по поиску и тд, это вопрос к бд, я пользуюсь постресом, и jsonb поможет даже со скалярными функциями по этому полю

Да, поправил сообщение. Не сразу как-то подумал)