ORM и системы типов

[metaclass]

Понял, почему меня всегда так бесят сабжи, и почему всегда хочется "сделать по своему, с преферансом и гимназистками".
Вообще ORM это попытка скрестить ужа и ежа, т.е. гонять данные из одной системы типов в другую. Мало того, что это само по себе печально, так еще обычно и первая и вторая системы типов страдают унылостью, да еще и по разному в разных СУБД и языках программирования.

Т.е. нормальный ORM должен быть сделан либо на некоем общем подмножестве всего что есть(которое или пустое или настолько мелкое что ничего не даст сделать) или использовать достаточно мощную систему типов, которая бы позволила имитировать работу и СУБД и объектных языков и без особого напряга подстраиваться к ним.

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

PS: Да, хорошее было бы название для фреймворка - snagehog :)

Comments

[wizzard]

Ага. Проекции типов вообще куда ни плюнь встречаются - компиляция, сериализация, орм, рендеринг, фильтры - это всё проекции типов.

Очень интересно бы вывести что-то, позволяющее декларативно их описывать, наподобие Linq. Причем поддерживающее денормализованные данные.

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

[clayrat.livejournal.com]

http://www-formal.stanford.edu/clt/FTN/MobileMaude/

[wizzard]

читаю

[metaclass.livejournal.com]

А в каком смысле "денормализованные"?

[wizzard]

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

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

[metaclass.livejournal.com]

Ууу, двунаправленный рекурсивный холокост.

[wizzard]

Именно)

[clayrat.livejournal.com]

а это уже migration =)

она и reflection - две краеугольные проблемы любой сложной системы.

[wizzard]

многие из них удавалось бы решить, кстати, если определиться хотя бы с понятием identity :)

[clayrat.livejournal.com]

в общем-то да

[w00dy.livejournal.com]

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

[metaclass.livejournal.com]

Нет, например тот же Hibernate - с одной стороны, он бывает и для жабы и для дотнета, с другой - для десятка-другого различной степени печальности баз данных.

[w00dy.livejournal.com]

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

Что касается баз - та их можно вынести в отдельные DB Provider-ы, которые выдают наружу 4 метода для работы с данными (select, insert, update, delete), три для транзакций (begin, commit и rollback), и умеют мапить типы языка в базу (тобишь кто-то будет мапить Guid в uniqueidentifier, кто-то в char(64)). Плюс орм должен позволять навешивать на поля кастомные value converter, который позволяет сконвертировать тип поля в один из стандартных языковых и наоборот. Этого достаточно чтобы покрыть если не все, то хотябы большую часть различных ситуаций.

[metaclass.livejournal.com]

Так в ADO базы уже вынесены в отдельные провайдеры. В принципе, этого даже хватает для работы с разными базами единообразно.
Вот чего реально не хватает в ADO - так это получения истинного типа селекта от сервера, т.е.
Параметр1 -> Параметр2 -> (Поле1,Тип,ИсточникДанных) -> (Поле2,Тип,ИсточникДанных) ..
В принципе, источник данных тут является частью типа, но система типов у SQL не настолько мощная, чтобы это описать.

Это все к чему - я обычно отчеты всякие описываю sql запросом, и если сервер возвращает такую информацию - практически весь гуй для отчета можно сгенерировать автоматически. А сейчас приходится к запросу еще дописывать вручную список параметров.


А насчет простых value converter - у типов в БД в некотором роде более сложная семантика, чем у жабо-дотнетовских - всякие там уникальные значения, внешние ключи, not null и check constraints. Поэтому обязательно вылезет какая-нибудь шиза, типа "проверить все ли правильно, можно только попытавшись сохранить в базу". А если база сидит за миддл-тиером это вырождается в тусование туда-сюда данных и сообщений об ошибках, что в отсутствие алгебраических типов данных сильно вгоняет в уныние.

[w00dy.livejournal.com]

> Так в ADO базы уже вынесены в отдельные провайдеры. В принципе, этого даже хватает для работы с разными базами единообразно.

Это, мы говорим об ORM или об ADO. Для orm ado это не более чем ещё один db provider.

> "проверить все ли правильно, можно только попытавшись сохранить в базу".

А это независимо от того пользуете ли вы орм, или напрямую инсерты делаете. Другое дело что всю эту кухню с проверками можно вынести на уровень того же орма, в каком-нить обработчике OnSaving плюс описать атрибутами чтобы орм правильную схему сгенерил.

[develop7]

К слову, знакомая коллега-жабист утверждает, что

…Доктрина уже переплюнула хибернейт по фичам.

И да, там всё так, как вы писали.

[metaclass.livejournal.com]

За сравнение мапперов для языков со статической и динамической типизацией нужно отправлять на каторжные работы по ручном написанию DAO объектов для пары тысяч таблиц :)

[yuripats.livejournal.com]

А вот тут больше написано http://citforum.ru/database/articles/vietnam/

[metaclass.livejournal.com]

Ага, нужно будет перечитать эту статью.

[sergiej.livejournal.com]

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

[blacklion.livejournal.com]

Ты про несовпадение импеданса и невозможность ORM читал классическую статью?

[metaclass.livejournal.com]

Какую из классических?:)
А невозможность ORM нам говорит как раз о том, что к нему подходят не с той стороны.

[golosptic.livejournal.com]

Доступ в реляционную базу данных должен быть встроен в язык программирования.
Таблица - это хэш бесконечного размера, для которого должны быть дополнительно введены операции, обеспечивающие транзакционную целостность
(Её, впрочем, и для обычных переменных можно было бы обеспечивать) и который должен существовать в режиме сохранения значений между прогонами программы.

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

[sleepy-drago.livejournal.com]

>имитация ужей методом сцепления ежей в списки
доставило! спасибо.
зы я не доктор Х. но ФП головного прогрессирует xD

[migmit.vox.com (from livejournal.com)]

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

Если этого ежа,
Нос заткнув, чтоб не дышал,
Где поглубже, бросить в речку -
Вы получите ерша.

Если этого ерша,
Головой в тисках зажав,
Посильней тянуть за хвост, то
Вы получите ужа.

Если этого ужа,
Приготовив два ножа...
Впрочем, он, конечно, сдохнет.
Но идея хороша.

[wizzard]

аплодирую.