bitbucket.org
Как вам такая орм?
инсертить можно произвольные поля, что позволяет заводить в таблицах любые автополя, не только "id", но и "created default not()" и прочие прелести.
В данном примере, если закоментировать строку 61, то модуль не скомпилируется, потому что поле "phone" входит всписок обязательных (type family ReqInsertFields)
Как вам такая орм?
инсертить можно произвольные поля, что позволяет заводить в таблицах любые автополя, не только "id", но и "created default not()" и прочие прелести.
В данном примере, если закоментировать строку 61, то модуль не скомпилируется, потому что поле "phone" входит всписок обязательных (type family ReqInsertFields)
pony orm. В котором все заметно лучше. В том числе и с DSL.
Этот DSL не вызывает желания помыть глаза с хлоркой.
Это что мне опять по новой DAO писать? Эээх я только в java от этого избавился при помощи spring-data. Может кто знает нет ли его
аналога для sqlalchemy?
stackoverflow.com — какое-то неполное и костыльное решение, к сожалению.
java.dzone.com
Фаулер про ORM. Фаулер говорит тоже самое что я думаю про ORM :)
Фаулер про ORM. Фаулер говорит тоже самое что я думаю про ORM :)
— Martin Fowler, съездив на конференцию, почувствовал боль в районе спины от того, что постоянно слышал иронию по отношению к ORM. В ответ он дал достаточно длинное описание того, что ORM — это сложно, что постоянный маппинг состояния от объектов к релационной БД — это сложно, ну и многое другое martinfowler.com
Мне показалось интересным.
* androrm.the-pixelpla.net — незапрещающая лицензия. Простая, легкая. Документация, примеры есть.
* activeandroid.com — Стоит денег (от 20 баксов). В стиле руби activerecord. Документация, примеры на сайте скудные (для коммерческой библиотеки).
* ormlite.com — незапрещающая лицензия. Выглядит несколько монструозно для андроидов. Много чего умеет, достаточно mature
* code.google.com — наколеночная поделка
эти внимательно не смотрел:
* github.com
* code.google.com
Да, вероятно, это можно как-то объяснить. Но зачем?
but then you might as well be using DataMapper. Except the Ruby library of the same name doesn't really implement the DataMapper pattern all that well either, having the same issue of tying it all together.
@classmethod'ы, только как методы ObjectManager'а. >_< Это не рельсовая ActiveRecord, где scope'ы и работа с коллекцией идет через методы класса. Это Django ORM, где такие задачи решаются через ObjectManager, и должны быть доступны по Model.objects.your_method. >_<
Никогда, сука, не пиши scope и методы коллекций как Но как оказалось, так делать не стоит, т.к. свойства объекта не могут так называться.
Разве что работать без ORM
Я не отрицаю, что есть много случаев, где Реляционные базы данных более оптимальные. Но в последнее время поголовных Социальных сервисо. Система примерно следующая:
1) Выбираем какой нибудь язык ( Java, Ruby, Python ).
2) Выбираем MVC Application Framework обязательно с ORM
3) Используем ORM когда данные принимаем.
4) Используем ORM когда данные меняем
5) Используем ORM когда данные отсылаем юзерю.
6) Гордо продолжаем пользоватся реляционной базой данных, с кучей Объектных настроек.
Вопрос: почему бы сразу не использовать no-sql базу данных, хранящую инфу в ввиде объектов, если все-равно на каждом этапе, таблицы каждый раз маршируются в объекты )) Где то платят за дополнительные съеденные такты процессора?
$models=FormPeriodType::model()->with(array('periodType', 'periodType.periods' => array('condition' => 'dt_start <= now()')))->findAll($criteria);
class Company(SQLObject):
_connection = db_con
class sqlmeta:
table = 'companies'
idName = 'CompanyId'
fromDatabase = True