Впечатления от Ruby On Rails 3

Уже больше недели безвылазно сижу в Chromium, Sublime Text2 и консоли. На подходе дедлайн по дипломному проекту, а у меня еще куча работы. После месяца упорных трудов с Flask, понял таки, что писать на нем большой проект с нуля - мне просто не по зубам. Не тот масштаб, и многое делать придется в ручную.
Ввиду того, что уже давно поглядываю на всем известные и нагремевшие Ruby On Rails, решил таки посмотреть, что там и как. По основным требованиям мне нужна была хорошая поддержка MongoDB, а также просто хорошие инструменты разработки для быстрого старта. На Python, среди таких инструментов мог бы оказаться Django, но вот проблема поддержки MongoDB - к сожалению актуальна в некотором плане.
Для начала осмотрелся с драйверами для MongoDB. Сразу подвернулся Mongoid. Взглянул на доки, пускай местами скудные, и во многом с ссылками на ActionRecord, но вещь оказалась более чем достойна внимания. Это поставило точку в моих терзаниях. С горькими слезами по тому, что таки на Python даже MongoKit не умеет таких прелестей, на какие способен Mongoid, я скрепя сердце создал новый проект на рельсах.

Поведение MongoKit для DBRef

Столкнувшись с проблемами в MognoKit при использовании вложенных массивов DBRef'ов и словарей с ними, у меня порой возникали ошибки при получении данных с этих документов. Я решил немного разобраться в этом поведении. Решил я идти не путем чтения кода, потому что, это заняло бы очень много времени, а так сказать, экспериментальным путем.

Начну по порядку. По умолчанию, когда вы имеете вложенные DBRef, то вы не можете явно искать по полям вложенных документов, так как база видит только DBRef. Например, если у вас есть документ поста блога, и в качестве автора DBRef на документ пользовательского аккаунта, то вы можете найти все посты автора используя запрос {'author.$id': author._id}.

Тоже самое поведение, и вызывало ошибки, когда я пытался получить внутренние данные именно пользовательского аккаунта. MongoKit dereference'ит только при явном запросе документа, будь он вложен в массив, или просто поле объекта. Поэтому, иногда нужно идти на ухищрения, и не паниковать, если возникают ошибки KeyError, или unicode не имеет метода или поля.

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

Это так же подтверждается, если вы загляните в Google Group проекта. Там много вопросов связанных именно с такими проблемами, хотя встречаются и ошибки. Так что, если у вас все таки какие-то проблемы возникли, смело обращайтесь к автору, он отзывчив и всегда помогает.

Приятного использования MongoKit.

P.S. Постараюсь выложить в дальнейшем код, для демонстрации. Если будет время, или не забуду.

MongoAlchemy - Внимание! Опасность!

Как и обещал, покопался малость в MongoAlchemy. Больше всего меня волновал вопрос поддержки отношений в базе. MongoAlchemy имеет поле DocumentField, как раз для встраивания документов.

Для проверки его работы, я решил написать небольшой тест. С двумя документами, который включает один в другой. В итоге, выяснил, что на самом деле, это не DBRef вовсе. MongoAlchemy просто копирует документ в другой документ, а не вставляет DBRef, и не dereference его.

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

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

Вывод: используйте MongoAlchemy аккуратно. Если ваш проект гарантирует то, что данные в базе не будут требовать отношений, то можете ее использовать. Но в любом случае, преимуществом будет использовать MongoKit, который на данный момент является лучшей ORM для MongoDB.

Краткий обзор ORM для MongoDB на Python

Постепенно интересуясь альтернативами MongoKit, я решил глянуть на альтернативы, и на то, что они предлагают. К сожалению, на данный момент, альтернатив в области Python MongoDB ORM мало, и они, не будем кривить душой, пока слабы. Но даже для их молодости, они уже вполне юзабельны, и могут использоваться. Во многом, здесь заслуга самой MongoDB, и разработчиков PyMongo.

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

Немного впечатлений от MongoDB, и WSGI-инструментария, в ходе разработки дипломного проекта

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

Конечно, все не так просто на деле, и с такого масштабного уровня, я опустился на более приземленный. Всего лишь bug tracker.

По пути, пришлось решить множество задач, которые с одной стороны и далеки от самой разработки, с другой стороны, они решают практически все в разработке дипломного проекта, как ПО. Задачи были связаны с выбором инструментальных средств, и вообще того, на чем это все будет держаться и строится. Благодаря этому, приобрел много опыта и главное впечатлений, от пробы того или иного инструментария. В основном, это касалось выбора хранилища данных, и инструментария для построения WSGI-приложения (с Python и WSGI, я определился уже очень давно, так как нравится и язык, и сама идея WSGI, и имеющиеся на данный момент инструменты, позволяют быстро и легко создавать приложения, при этом не мучаясь с организацией приложения, как это происходит в PHP, к примеру).

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