Во-первых, спасибо за еще один вариант решения проблемы. Посмотрел. Идея та же самая.
Цитата:
Изначально опубликовано Wamr
- уникальный индекс не всегда есть
А мне он и не нужен. Был бы какой-нибудь
Когда я писал, столкнулся с такой проблемой: как-то надо было выбрать множество полей, по которому строить методы. Самым разумным вариантом мне показалось, выбрать какой-либо индекс. В том классе, который ты мне отправил, действительно выбирается первый уникальный индекс. Я предоставил выбор (и ответственность
) пользователю: перед созданием можно выбрать индекс, который будет использоваться.
Цитата:
Изначально опубликовано Wamr
- find и пр. на временных таблицах большого смысла иметь не будут.
Не запускайте Job на временных таблицах
А вообще, задался таким вопросом (но не успел его решить): в зависимости от вида элемента, выбранного в AOT, отображаются не все AddIns (например, Браузер таблиц для классов не вызывается). Как это организована? Любая помощь, как говорится, приветствуется.
Цитата:
Изначально опубликовано Wamr
- было бы неплохо создавать все 4 метода (хотя checkExist, txtNotExist редко встречаются)
Их мне представляется более целесообразным создавать в виде Template. Моя точка зрения примерно такая: то, что можно после создания сразу использовать, стоит вынести в AddIns, то, что нужно доработать - в Template. Эти методы, как мне представляется, как раз для того и существуют, чтобы "оразнообразить" процесс ненахождения записи в таблице.
В заключение, выложу новую версию проекта. Пусть это будет, например, версия 0.5.
Изменения:
- Вместо атомарных типов подставляются соответствующие базовые EDT.
- Используются метки.