to post messages and comments.

bitbucket.org
Как вам такая орм?
инсертить можно произвольные поля, что позволяет заводить в таблицах любые автополя, не только "id", но и "created default not()" и прочие прелести.
В данном примере, если закоментировать строку 61, то модуль не скомпилируется, потому что поле "phone" входит всписок обязательных (type family ReqInsertFields)

Мда. Работал я себе с ним через чистый SQL. Но решил посмотреть там ORM. Да емае че за гребанный закат солнца в ручную?
Это что мне опять по новой DAO писать? Эээх я только в java от этого избавился при помощи spring-data. Может кто знает нет ли его
аналога для sqlalchemy?

А кто-нибудь знает культурный путь для добавления префильтров в ORM алхимии? Я бы такой, что бы на уровне ORM-моделей пофильтровал все записи, недоступные пользователю.
stackoverflow.com — какое-то неполное и костыльное решение, к сожалению.

This is where I sympathize greatly with Ted Neward's famous quote that object-relational mapping is the Vietnam of Computer Science.

— Martin Fowler, съездив на конференцию, почувствовал боль в районе спины от того, что постоянно слышал иронию по отношению к ORM. В ответ он дал достаточно длинное описание того, что ORM — это сложно, что постоянный маппинг состояния от объектов к релационной БД — это сложно, ну и многое другое martinfowler.com

Мне показалось интересным.

если вам надо простую ORM для андроида, то есть:

* androrm.the-pixelpla.net — незапрещающая лицензия. Простая, легкая. Документация, примеры есть.
* activeandroid.com — Стоит денег (от 20 баксов). В стиле руби activerecord. Документация, примеры на сайте скудные (для коммерческой библиотеки).
* ormlite.com — незапрещающая лицензия. Выглядит несколько монструозно для андроидов. Много чего умеет, достаточно mature
* code.google.com — наколеночная поделка

эти внимательно не смотрел:
* github.com
* code.google.com

Гениально! К поекту на django прикручен django-cms orm(я думал, что это тоже самое, что и django orm, но говорят, что это не так). А для самых сложных запросов используется SQLAlchemy!
Да, вероятно, это можно как-то объяснить. Но зачем?

Никогда, сука, не пиши scope и методы коллекций как @classmethod'ы, только как методы ObjectManager'а. >_< Это не рельсовая ActiveRecord, где scope'ы и работа с коллекцией идет через методы класса. Это Django ORM, где такие задачи решаются через ObjectManager, и должны быть доступны по Model.objects.your_method. >_<

Вот почему. Почему нигде в доке джанги я не нашел даже малейшего упоминания о том, что при неправильном поле (к примеру, поле установленно null=False), при сохранении модели вызывается исключение IntegrityError. И тут нихуя не очевидно, что такое есть. Есть ValidationError, если не проходит валидация. Но это только через валидаторы. Пиздец. Я зол. А раньше считал доки по Django лучшими в своем роде. Сейчас уже так давно не считаю, увы.

*внезапно Внезапно, а Django умеет подхватывать обратные связи o2m, m2m и так далее. Однако с каким синтаксисом это делается, мне честно говоря дико не привычно. А еще ни хрена не понятно, что она собственно делает, и какие запросы там шлет ( Вот блин. Делают джангу уже сколько лет. У них 1 ORM, главная. Неужели так трудно блин сделать dev-консоль как у Rails которая будет выводить статистику и логи по запросам и скорости обработки рендеринга, запросов и прочего. Чтобы не ставить каждый раз django-debug-tools. Ну это звездец товарищи, но средства для разработки не входят в стандартную поставку. Это звездец звездец (((((((( А вы еще про магию рельсов говорите.

Слышал мнение, что ORMки не нужны, т.к. SQL — хороший, годный язык запросов, который затачивался под свои нужды, и кроме него ничего не нужно, а ORMки — лишь мода, которая пройдёт. Отчасти согласен, в ORM некоторые вещи делаются через костыли, а то и вообще не делаются никак, к тому же эффективность уже не та. Иожно было бы и использовать себе SQL, для закрытых проектов это нормально — СУБД меняется крайне редко, а вот как быть для открытых проектов, когда каждый пользователь хочет использовать привычную ему СУБД? Как достигнуть совместимости при использовании Raw SQL? Писать и отлаживать код, работающий с СУБД столько раз, сколько нужно поддерживаемых СУБД? Тогда чем этот костыль принципиально лучше ORM, для которого можно написать один раз и особо не переживать, что на другой СУБД работать откажется?

Интересует ваше мнение: Предположим есть минималистичный RESTful веб сервис (только веб сервис, без страниц и тд и тп). В качестве DB используеться no-sql json хранилище. Стали бы вы писать ORM/AR прослойку, или забили бы? Ну и конечно — почему да или нет.

Мой новый php класс для автоматического составления SQL запросов на основе построеной "цепочки" параметров и выполнения запросов через подключаемый драйвер БД.
Если есть желающие потестить или ознакомиться:
code.google.com

они там вообще охуели?! Visual Studio Support — рисование ER-диаграмм в тормозной студии за 100500 баксов. сраного говна куча промежуточных файлов, необходимость вносить изменения в over 9000 мест и прочее — где профит?!

orm

а еще меня радуют ORG + SQL базы данных ^_^
Я не отрицаю, что есть много случаев, где Реляционные базы данных более оптимальные. Но в последнее время поголовных Социальных сервисо. Система примерно следующая:
1) Выбираем какой нибудь язык ( Java, Ruby, Python ).
2) Выбираем MVC Application Framework обязательно с ORM
3) Используем ORM когда данные принимаем.
4) Используем ORM когда данные меняем
5) Используем ORM когда данные отсылаем юзерю.
6) Гордо продолжаем пользоватся реляционной базой данных, с кучей Объектных настроек.

Вопрос: почему бы сразу не использовать no-sql базу данных, хранящую инфу в ввиде объектов, если все-равно на каждом этапе, таблицы каждый раз маршируются в объекты )) Где то платят за дополнительные съеденные такты процессора?

отправил два багрепорта по django orm, оба по поводу совместимости с pgsql, первый уже заапрувили, второй только что отправил, посмотрим на отзывчивость тамошних разрабов