Generate DB Script - INIT TABLES

Есть некая сущность (Entity) с общими для всех потомков атрибутами и десяток потомков, которые имеют свои собственные атрибуты (стратегия Single Table). Но кроме этого, часть из этих собственных атрибутов перекрываю друг-друга, например, для двух потомков характерен атрибут “длина”.
Сейчас при генерации таблиц (закладка INIT TABLES) в запрос create table этот атрибут попадает дважды, что вызывает ошибку при его выполнении.

Что интересно, скрипты обновления (UPDATES) такой “ошибки” не допускают.

Здравствуйте, Михаил.

Спасибо, что сообщиили о проблеме. Завёл тикет в YouTrack: ссылка.

Даниил.

1 симпатия

Даниил, доброго дня.

Я так понимаю в последней студии этот тикет закрыли. Но решение кажется мне странным.
Сейчас я попросту не могу сгенерировать скрипты для описанной выше ситуации:

Table 'WEDB_ACTIVITY' contains duplicate columns 'FS_TECHNICIAN_ID'. Please, check entities: 'com.borets.wedb.entity.ActivityPull' and 'com.borets.wedb.entity.ActivityFailure' See studio.log file for more details

Каков предполагаемый выход из нее? Наследование не подходит так как множественным быть не может. Интерфейсы? По-моему и он не позволят решить вопрос.

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

Добрый, Евгений.

Получилось достаточно забавно… :sweat_smile: Ранее студия генерировала “неправильные” скрипты создания БД, со скриптами обновления все было нормально. Теперь же я просто не могу сгенерировать ни тех, ни других.

Хорошо. Что делать, если я уже ее использую в системе, в которой есть данные?

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

Постараюсь прояснить проблему и наше решение ограничить функциональность Studio.

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

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

Какой может быть миграция, если вы всё-таки воспользовались этой недоработкой:

  • Создайте скрипт обновления (вручную), который создаст дополнительные копии колонки с другим именем и скопирует данные.
  • Измените имена атрибутов и связанных колонок в коде сущностей.
  • Выполните обновление БД - Studio сможет продолжить работать с вашей моделью.
  • Если какие-то колонки используются во всех наследниках (или почти во всех), то разместите их в основной сущности-предке.

При необходимости единообразно работать с наследниками из Java кода, вы можете использовать Java интерфейсы (как вы упоминали) и реализовывать их в нужных наследниках.

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

2 симпатии