Посоветуйте ORM для питона..
Приоритеты:
— скорость работы с базой;
— скорость разработки;
— возможность оптимизации sql-ных запросов врукопашку;
— поддержка нескольких баз в пределах одного приложения.
говорят, у джанги ORM не шибко шустрый и оптимальный, хочется подменить..
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, kochetkov.vladimir, Вы писали:
F>>>Посоветуйте ORM для питона.. KV>>http://www.sqlalchemy.org/ ?
F>да, в курсе.. но хочется ещё умных рассуждений, которые бы меня окончательно и бесповоротно убедили бы в гениальности алхимии..
В общем то, возможности, как я понял, везде одинаковые. Немного разные
подходы.
SqlObject требует, чтобы все объекты были наследником от ихнего класса и за
счет этого связывают объект и таблицу. В SqlAlchemy эта операция связывания
(маппинга) выполняется явно.
Dejavu, насколько я понял, проектируется так, чтобы от пользователя был
вообще скрыт сам факт существования базы данных.
Здравствуйте, kochetkov.vladimir, Вы писали:
F>>>>Посоветуйте ORM для питона.. KV>>>http://www.sqlalchemy.org/ ? F>>да, в курсе.. но хочется ещё умных рассуждений, которые бы меня окончательно и бесповоротно убедили бы в гениальности алхимии.. KV>Сие читал? Вроде достаточно умные...
не читал, почитаю..
меня больше интересует то, как вписывается алхимия в перечисленные мной пункты
Здравствуйте, Daevaorn, Вы писали:
F>>говорят, у джанги ORM не шибко шустрый и оптимальный, хочется подменить.. D>А на Западе говорят. что в Москве медведи в ушанках ходят по улицам, м что?
так ведь правда ходят..
D>Во что вы уперлись? При какой нагрузке? Алгоритмически уже всё оптимизировали?
я ищу альтернативы на будущее, т.к по моим сведениям проблемы есть..
Здравствуйте, neFormal, Вы писали:
F>так ведь правда ходят..
Нет.
F>я ищу альтернативы на будущее, т.к по моим сведениям проблемы есть..
F>по теме есть что сказать?. ~_^
При такой постановке вопроса — нет. Т.е. вопроса нет как такового. Абстрактное — "есть проблемы, какие не знаю, но хочу их решить сменой инструмента" — это не инженерный подход.
Если бы были объективные метрики, говорящие, что здесь и здесь ОРМ лажает, а это критично, то тут можно было что-то посоветовать.
Здравствуйте, Daevaorn, Вы писали:
F>>по теме есть что сказать?. ~_^ D>При такой постановке вопроса — нет. Т.е. вопроса нет как такового. Абстрактное — "есть проблемы, какие не знаю, но хочу их решить сменой инструмента" — это не инженерный подход.
читай внимательней — я просил посоветовать ORM для Python, а не подсказать альтернативу Django..
D>Если бы были объективные метрики, говорящие, что здесь и здесь ОРМ лажает, а это критично, то тут можно было что-то посоветовать.
оф.джанга, насколько я знаю, не поддерживает несколько СУБД в пределах одной аппликухи..
все сторонние наработки, которые я видел, выглядят стрёмно и не всегда работают..
посоветуй красивый и рабочий вариант?.
да и по прочим пунктам в начальном посте тоже можно что-либо сказать..
Здравствуйте, neFormal, Вы писали:
F>оф.джанга, насколько я знаю, не поддерживает несколько СУБД в пределах одной аппликухи.. F>все сторонние наработки, которые я видел, выглядят стрёмно и не всегда работают.. F>посоветуй красивый и рабочий вариант?.
sqlalchemy умеет, открываешь 2 две сесии и вперед.
Здравствуйте, achmed, Вы писали:
F>>оф.джанга, насколько я знаю, не поддерживает несколько СУБД в пределах одной аппликухи.. F>>все сторонние наработки, которые я видел, выглядят стрёмно и не всегда работают.. F>>посоветуй красивый и рабочий вариант?. A>sqlalchemy умеет, открываешь 2 две сесии и вперед.
Здравствуйте, neFormal, Вы писали:
F>Посоветуйте ORM для питона.. F>Приоритеты: F>- скорость работы с базой; F>- скорость разработки; F>- возможность оптимизации sql-ных запросов врукопашку; F>- поддержка нескольких баз в пределах одного приложения.
F>говорят, у джанги ORM не шибко шустрый и оптимальный, хочется подменить..
Посоветовать не посоветую, скажу пару слов об алхимии.
Мне она не очень понравилась — хотя и гораздо более зрелый ОРМ, по сравнению с джанговским, с большим функционалом, есть в ней несколько странных решений. Для простых проектов их не замечаешь, для сложных все может стать сложнее .
Про связку с mysql: очень странно реализован autocommit = true. По стандарту, после создания соединения с базой, опция автокоммита должна быть выключена, даже если она в явном виде вклюается в connection_params. Видимо поэтому (и, наверное, чтобы написать один и тот же код для разных БД), в адхимии autocommit = true эмулируется руками. Ну то есть они натурально парсят все запросы к серверу и коммитят insert/update/delete/etc.
Вторая странность — видимо, тоже, чтобы написать один и тот же код для всех БД, при возвращении соединения в пул, алхимия сама говорит в него rollback. В принципе, ничего фатального, даже спасает от некоторых ошибок, но, блин, по меньшей мере странно.
