ORM?

[metaclass]

Цитата из статьи с сайта NHibernate, про то, "как использовать NHibernate с legacy базами, где в поле для внешней ссылки без значения ставят 0 вместо null":
"NHibernate is bad in many aspects, but the only thing we can’t blame is extensibility."
и далее - бездны ада и конфигурации NHibernate для этого частного случая.
Заодно глянул во внутренности NHibernate, класс Dialect, посмотреть, как же они реализовали работу с различными СУБД. около 150 методов, из них около 50 - bool флаги на тему "поддерживается ли эта фича"/"расположена фича до или после запроса", около 80 - "какая строка нужна для реализации этой фичи до запроса/после запроса" и тому подобное.
Особенно стремно выглядит работа с identity/sequence и прочими автогенерируемыми первичными ключами.
В общем, внутренности ORM кромешно адовы, а когда язык не позволяет метапрограммирование хоть как-то - там вообще холокост.

Это ж я все по поводу айсед-дотнет-срача (http://theiced.livejournal.com/143962.html) пытаюсь понять, может я все-таки не прав, и готовыми либами все-таки можно пользоваться и они не будут выворачивать мозг наизнанку от осознания того, что их авторы умеют хорошо программировать, но не понимают, что они делают с точки зрения теории.

Т.е. у меня идея такая: если в основе технологии лежит грамотная и проработанная теоретическая модель - ей легко пользоваться, она помещается в мозг и технология будет реализована более-менее однообразно.
А когда это сделано на основе ad-hoc бреда, рассчитано на фабрики из сотен индусов, вручную рисующих в вижуал-студии диаграммы и дорабатывается по принципу "что попросил vip-клиент из Бразилии" - то пользоваться этим белому человеку невозможно.
Если же базовая модель не проработана, то даже при наличии стандартов будет стопицот реализаций, одна другой страшнее и у каждой будут свои пропоненты, все аргументы которых сводятся к одному "я использую эту технологию 5 лет и у меня нет никаких проблем с ней никогда".
А правильный аргумент должен быть "я про эту технологию слышал раньше, прочитал 100 страниц вчера, сегодня налабал прототип софтины, а через год мне не нужно будет стоять в раскоряку на гамаке в скафандре, чтобы дорабатывать софтину в соответствии с изменившимися требованиями".

Comments

[feorex.livejournal.com]

А какую ORM использует ребе в своих проектах?

[fraks-nsk.livejournal.com]

А зачем их вообще использовать? Они ведь только мешают общению с базой на нормальном sql-языке, являются лишней прокладкой со своими червями.

[metaclass.livejournal.com]

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

[(Anonymous)]

sqlalchemy смотрел? если да, то что в нем не так?

[metaclass.livejournal.com]

Питон в нем не так.

[avnik.livejournal.com]

ребе, чем _вам_ то петон не угодил? (чем он не угодил голосам в голове уважаемого ребе Айседа -- я в курсе уже)

[metaclass.livejournal.com]

Тем, что мне придется 15 лет работы переписать с нуля на нем :)

[avnik.livejournal.com]

Ну вы бы с SQLAlchemy все таки ознакомились? Может все 15 и не прийдется переписывать (там в общем уже столько понаписано всего...)

[avnik.livejournal.com]

Хороший орм никогда не мешает написать запрос ручками.
Польза от них -- избавление от заката солнца вручную, в тех местах которые пишутся 95% времени разработки, и при жизни проекта выполняются редко и на малом объеме данных. (и от считания на пальцах -- в каком по счету элементе кортежа будет foo.bar из select ...., foo from bar, ... когда там полей так 40 из разных таблиц)

[tzirechnoy.livejournal.com]

В каком, нафиг, элементе? Поля результата именованные.

[metaclass.livejournal.com]

Это не помогает, если ошибку в имени поля сделать.

[tzirechnoy.livejournal.com]

То есть я ужэ два голоса вижу за static type check.

Но static type check я не люблю как таковой, так что мне это... Ну, то есть, можно -- но лучшэ, чтобы отдельно от языка, и не мешалось.

[norguhtar.livejournal.com]

Чтобы не закатывать вручную солнце в CRUD.

[metaclass.livejournal.com]

Я MDA использую - у меня все генерируется из моделей. В том числе и код, который гоняет данные между объектам и базой данных.
Вот подумывал упростить себе жизнь и генерить NHibernate маппинги - но уже глянул, что кое-какие нужные мне фичи там реализованы кривовато.

[hamster37.livejournal.com]

Мне интересно как это у вас реализовано: что есть в моделях, и как реализована связка генерящегося кода и того, который пишется руками? Я с ходу вижу два варианта: 1) генерятся отдельные модули, которые руками не правятся, и эти модули предоставляют какой-то апи для остальных; 2) есть свой препроцессор и генерящийся код вставляется в рукописный прямо перед компилляцией. Или что-то другое?

[metaclass.livejournal.com]

Генерятся неизменные модули (sql-скрипты, c# классы, xml-метаданные для гуи-редакторов), они окружаются самописным кодом, предоставляют API или расширяются по мере необходимости, как partial классы в C#.

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

[hamster37.livejournal.com]

> Генерятся неизменные модули (sql-скрипты, c# классы, xml-метаданные для гуи-редакторов), они окружаются самописным кодом, предоставляют API или расширяются по мере необходимости, как partial классы в C#.

это понял, спасибо

> Модель генерится этим же кодогенератором. В смысле, что модели хранятся в базе данных, сгенерированной из самой же себя.

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

[metaclass.livejournal.com]

Обновление структуры данных да, геморрой ручной.
Другое дело, что он в любом случае таков, миграции умеет мало кто, особенно сложные, там с нижележащей теорией все весьма и весьма хреново.

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

[hamster37.livejournal.com]

понял. То-есть, если для моделек генерятся классы, то этот метатулз наверно тоже можно считать ORM-ом с генерацией кода.

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

[metaclass.livejournal.com]

С контролем версий проблема. Есть софтина, которая экспортирует содержимое моделей в текст и умеет из этого текста и заранее сгенерированных исходников создать базу с нуля.
И оный текст уже хранится под контролем версий. Проблема - в лишнем этапе "запуск софтины", который можно забыть.
И в том, что работать реально можно только на одной базе, живущей на работе, т.е. поработать с моделями на своем домашнем/носимом компе, без доступа к центральной базе сложновато, максимум что можно сделать - создать базу и отлаживаться на ней, а потом по результатам модифицировать основную базу, чтобы не было конфликтов.

Я подумываю сделать вместо базы с моделями какой-нить структурированный текст, xml,json,csv, без разницы что, и использовать его как хранилище. Размеры там мизерные, зато контроль версий будет от входа.