Синхронизация моделей данных
От: Shamann  
Дата: 26.11.12 13:56
Оценка:
Добрый день.

Необходим совет.
Пришла в голову идея создания встраиваемого в среду разработки (например, Eclipse) модуля синхронизации ORM. Целью данной фичи является помощь разработчику в переносе изменений в маппинг и схему БД при внесении изменений в структуру классов и наоборот. Таким образом, будет поддерживаться "синхронность" состояний системы классов и схемы БД.
В этом направлении, конечно, кое-что уже сделано. Но все встреченные мной инструменты работали только на принципе автогенерации (т.е. при изменении одной из моделей — классов или БД — другая модель генерируется полностью заново по жестко заданным шаблонам). Я же хочу организовать инкрементальный перенос изменений. Также не поддерживаются наследование, различные стратегии маппинга (связку классов можно по-разному отобразить в БД) и т.д. Все эти факты я хочу учесть при разработке. Конечная цель — как можно меньше делать вручную при внесении изменений.
Как Вы думаете, стоит ли создавать подобного рода инструмент? Есть ли у Вас какие-либо мысли по этому поводу?
Спасибо.
dayabase java
Re: Синхронизация моделей данных
От: mogikanin Россия  
Дата: 26.11.12 14:23
Оценка:
В EntityFramework уже больше года есть Code First Migrations.
Re[2]: Синхронизация моделей данных
От: Shamann  
Дата: 26.11.12 16:29
Оценка:
Здравствуйте, mogikanin, Вы писали:

M>В EntityFramework уже больше года есть Code First Migrations.


Согласен, но во-первых, это только одна сторона дела. Если нужно внести в модель классов какие-либо изменения со стороны БД, придется самому создавать классы и маппить их вручную. Во-вторых, основная часть работы по переносу изменений делается вручную. Кроме того, насколько я понял, алгоритм создания миграции задан жестко и не позволяет реализовывать различные стратегии маппинга (ту же структуру из двух классов, один из которых наследуется от другого, можно по-разному отобразить в БД) и сгенеренный вариант миграции все равно правится вручную. Я не говорю о том, что участие пользователя не нужно — полной автоматизации здесь вряд ли можно добиться, но, на мой взгляд, слишком много ручной работы и часть ее можно автоматизировать.
Re[3]: Синхронизация моделей данных
От: Aikin Беларусь kavaleu.ru
Дата: 27.11.12 08:12
Оценка:
Здравствуйте, Shamann, Вы писали:

S>Здравствуйте, mogikanin, Вы писали:


M>>В EntityFramework уже больше года есть Code First Migrations.


S>Согласен, но во-первых, это только одна сторона дела. Если нужно внести в модель классов какие-либо изменения со стороны БД, придется самому создавать классы и маппить их вручную. Во-вторых, основная часть работы по переносу изменений делается вручную. Кроме того, насколько я понял, алгоритм создания миграции задан жестко и не позволяет реализовывать различные стратегии маппинга (ту же структуру из двух классов, один из которых наследуется от другого, можно по-разному отобразить в БД) и сгенеренный вариант миграции все равно правится вручную. Я не говорю о том, что участие пользователя не нужно — полной автоматизации здесь вряд ли можно добиться, но, на мой взгляд, слишком много ручной работы и часть ее можно автоматизировать.

Ну тогда предлагаю глянуть на джанговский south:

South has a few key features:
Automatic migration creation: South can see what’s changed in your models.py file and automatically write migrations that match your changes.
Database independence: As far as possible, South is completely database-agnostic, supporting five different database backends.
App-savvy: South knows and works with the concept of Django apps, allowing you to use migrations for some of your apps and leave the rest to carry on using syncdb.
VCS-proof: South will notice if someone else commits migrations to the same app as you and they conflict.

Чтобы все это заработало в модели нужно хранить много метаданных.
И класический вопрос:
Было:
class Knight(models.Model):
    name = models.CharField(max_length=100)
    of_the_round_table = models.BooleanField()
    dances_whenever_able = models.BooleanField()
    shrubberies = models.IntegerField(null=False)


Стало:
class Knight(models.Model):
    fullname = models.CharField(max_length=100)
    of_the_round_table = models.BooleanField()
    dances_whenever_able = models.BooleanField()
    shrubberies = models.IntegerField(null=False)


Это мы переименовали поле или же удалили старое и создали новое?

СУВ, Aikin
... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>
Re[4]: Синхронизация моделей данных
От: Shamann  
Дата: 27.11.12 09:15
Оценка:
Спасибо за отсылку к South.
Однако, насколько я понимаю, он также служит целям трансформации изменений модели классов в схему БД, а также создания процедуры миграции со старой схемы БД на новую. Также, как я понял, вопросы применения различных стратегий трансформации остаются на стороне пользователя, а перенос изменений из схемы БД в структуру классов не предусматривается (осмотрел очень бегло, так что, возможно, неправ).
Информация, необходимая для принятия решений о той или иной стратегии трансформации, как Вы верно сказали, будет иметь вид метаданных. Однако, при грамотном подходе и реализации механизма принятия решений это позволит более-менее сносно трансформировать модели различными способами и не приведет к созданию большого количества метаданных.
По крайней мере можно использовать показатели, характеризующие использование тех или иных структур данных (насколько часто данные извлекаются, модифицируются и т.п.) — я думаю, этого будет вполне достаточно.
Что касается вопроса об изменениях в структуре классов, то, разумеется, если использовать текстовое представление модели, то будет сложно понять, что же произошло. Использование визуального редактора, по крайней мере, поможет различить операции переименования и создания/удаления. Кроме того, этот вопрос важен лишь для данных в БД, но не для самой схемы БД.
Re[5]: Синхронизация моделей данных
От: Aikin Беларусь kavaleu.ru
Дата: 27.11.12 09:26
Оценка:
Здравствуйте, Shamann, Вы писали:


S>а перенос изменений из схемы БД в структуру классов не предусматривается (осмотрел очень бегло, так что, возможно, неправ).

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

S>Информация, необходимая для принятия решений о той или иной стратегии трансформации, как Вы верно сказали, будет иметь вид метаданных. Однако, при грамотном подходе и реализации механизма принятия решений это позволит более-менее сносно трансформировать модели различными способами и не приведет к созданию большого количества метаданных.

S>По крайней мере можно использовать показатели, характеризующие использование тех или иных структур данных (насколько часто данные извлекаются, модифицируются и т.п.) — я думаю, этого будет вполне достаточно.
Show me the code. Пока это выглядит как "бла-бла-бла мы новый мир построим". Дьявол в деталях.

S>Что касается вопроса об изменениях в структуре классов, то, разумеется, если использовать текстовое представление модели, то будет сложно понять, что же произошло. Использование визуального редактора, по крайней мере, поможет различить операции переименования и создания/удаления.

Стоп, вот у нас есть 2 сущности: модель в коде и схема данных в БД. Чтобы их синхронизировать вы предлагаете добавить третью (данные для визуального редактора)?


S>Кроме того, этот вопрос важен лишь для данных в БД, но не для самой схемы БД.

Если рассматривать схему в отрыве от данных, то лучший вариант: drop/create -- никаких неоднозначностей.


СУВ,
... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>
Re[6]: Синхронизация моделей данных
От: Shamann  
Дата: 27.11.12 09:57
Оценка:

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


Да, такие инструменты есть. Но проблемы те же: автогенерация модели классов с нуля, недостаток выразительности и "оторванность" от синхронизации в другом направлении (от классов к схеме), что заставляет использовать два разных инструмента на разных стадиях разработки. Однако перенос изменений из базы в структуру классов необходим не только на начальных этапах. Допустим, может возникнуть ситуация, когда нужно объединить базы двух разных приложений, а использовать структуру классов со стороны Вы по каким-то соображениям не хотите.


Show me the code. Пока это выглядит как "бла-бла-бла мы новый мир построим". Дьявол в деталях.


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


Стоп, вот у нас есть 2 сущности: модель в коде и схема данных в БД. Чтобы их синхронизировать вы предлагаете добавить третью (данные для визуального редактора)?



Модель классов может быть не только в коде. Строго говоря, модель — это не обязательно сам код. Допустим, если Вы обратите внимание на такие инструменты, как EMF, например, то обнаружите, что модель представлена в виде диаграммы классов в визуальном редакторе и уже по этой модели генерируется готовый код. Не вижу в таком подходе ничего предосудительного.
Re[7]: Синхронизация моделей данных
От: Aikin Беларусь kavaleu.ru
Дата: 27.11.12 10:54
Оценка: +1
Здравствуйте, Shamann, Вы писали:

S>Модель классов может быть не только в коде. Строго говоря, модель — это не обязательно сам код. Допустим, если Вы обратите внимание на такие инструменты, как EMF, например, то обнаружите, что модель представлена в виде диаграммы классов в визуальном редакторе и уже по этой модели генерируется готовый код. Не вижу в таком подходе ничего предосудительного.

Не-не-не (Дэвид Блэйн), век RADов, визуальных редакторов и "уже по этой модели генерируется готовый код" закончился в начале тысячелетия. Туда им и дорога. Аминь.

СУВ, Aikin
... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>
Re[8]: Синхронизация моделей данных
От: Shamann  
Дата: 27.11.12 11:29
Оценка:
Здравствуйте, Aikin, Вы писали:

A>Здравствуйте, Shamann, Вы писали:


S>>Модель классов может быть не только в коде. Строго говоря, модель — это не обязательно сам код. Допустим, если Вы обратите внимание на такие инструменты, как EMF, например, то обнаружите, что модель представлена в виде диаграммы классов в визуальном редакторе и уже по этой модели генерируется готовый код. Не вижу в таком подходе ничего предосудительного.

A>Не-не-не (Дэвид Блэйн), век RADов, визуальных редакторов и "уже по этой модели генерируется готовый код" закончился в начале тысячелетия. Туда им и дорога. Аминь.

A>СУВ, Aikin


Скажем так... найдется множество людей, с Вами несогласных)) Ну да ладно, не будем разводить холивар, Вашу позицию я понял и большое Вам спасибо.
Re: Синхронизация моделей данных
От: bl-blx Россия http://yegodm.blogspot.com
Дата: 27.11.12 13:46
Оценка:
Здравствуйте, Shamann, Вы писали:

S>Добрый день.


S>Необходим совет.

S>Пришла в голову идея создания встраиваемого в среду разработки (например, Eclipse) модуля синхронизации ORM. Целью данной фичи является помощь разработчику в переносе изменений в маппинг и схему БД при внесении изменений в структуру классов и наоборот. Таким образом, будет поддерживаться "синхронность" состояний системы классов и схемы БД.
S>В этом направлении, конечно, кое-что уже сделано. Но все встреченные мной инструменты работали только на принципе автогенерации (т.е. при изменении одной из моделей — классов или БД — другая модель генерируется полностью заново по жестко заданным шаблонам). Я же хочу организовать инкрементальный перенос изменений. Также не поддерживаются наследование, различные стратегии маппинга (связку классов можно по-разному отобразить в БД) и т.д. Все эти факты я хочу учесть при разработке. Конечная цель — как можно меньше делать вручную при внесении изменений.
S>Как Вы думаете, стоит ли создавать подобного рода инструмент? Есть ли у Вас какие-либо мысли по этому поводу?
S>Спасибо.

В идеале, хотелось бы схему базы описывать, скажем, на уровне классов и, к примеру, JPA-аннотаций
(хотя, мне кажется, JPA будет недостаточно). При этом среда разработки должна быть достаточно умна,
чтобы реагировать на различные рефакторинги типа переименования свойства, предлагая создание
соответствующего миграционного скрипта. Серьёзная проблема в том, как обнаружить рефакторинги,
сделанные вручную. Интересный случай, кстати, когда меняется тип свойства, например, int расширяется
до double, или String в Date/int и т.п.
Очевидно также, что инкрементальные обновления должны очень четко и легко версионироватся, например,
подобно тому как реализовано в LiquiBase. Это позволило бы избавиться от самодельных средств синхронизации
при колективной разработке.
El pueblo unido jamás será vencido.
Re: Синхронизация моделей данных
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 05.12.12 23:12
Оценка:
Здравствуйте, Shamann, Вы писали:

S>Я же хочу организовать инкрементальный перенос изменений.


А в чем смысл инкрементальных изменений в коде?
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
AVK Blog
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.