Django-nonrel против Django-mongodb против Mongokit против родного pymongo

Работаю над проектом Django, для которого требуется хранилище NoSQL, и я думаю, что остановился на Mongo. Я видел много тем, в которых говорится о Mongo и Django, но ни в одной из них не упоминался Django-nonrel, и я не понимаю, почему его могли дисквалифицировать, но у меня нет опыта ни с одним из них.

В идеале я хотел бы сохранить хранилище SQL для простых вещей, аутентификации пользователей, групп и т. д. и использовать Mongo для больших данных.

Я также хотел бы, чтобы мои объекты, хранящиеся в Mongo, были классами в стиле Django-ORM, чтобы у меня было похожее «ощущение», но это не критично.

Наконец, позволяет ли что-либо из вышеперечисленного мне использовать поддержку нескольких баз данных Django для чего-либо, или все мои запросы mongo фактически «вне диапазона» от Django ORM?

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


django mongodb pymongo django-nonrel mongokit
person bmelton    schedule 03.05.2012    source источник
comment
Да, с Django и MongoDB можно работать, я сам так делал пару лет назад. Я не пробовал Django-nonrel, но если вы хотите использовать SQL для простых вещей, вам следует придерживаться оригинального Django. Вы уже должны знать, что у Django нет бэкенда Mongo, но если вы хотите сохранить ощущение Django ORM, вам действительно стоит попробовать mongoengine .   -  person César    schedule 03.05.2012
comment
Я поддерживаю рекомендацию для mongoengine.   -  person Justin    schedule 03.05.2012

Ответы (2)


arrow_upward
5
arrow_downward

Django-nonrel — это способ использовать Django в MongoDB. Есть django-mongodb.org, но он просто создан поверх Django-nonrel. В списке рассылки django-nonrel происходит довольно много активности mongodb.

Хранение ваших классов монго в виде объектов Django ORM работает нормально, в этом весь смысл.

Я не пробовал использовать поддержку нескольких баз данных вместе с SQL. Я не видел, чтобы многие люди использовали его таким образом, и я подозреваю, что он, скорее всего, не работает. Есть некоторая работа по перемещению django-nonrel, чтобы официально стать частью Django 1.4, я подозреваю, что это сработает после того, как это будет завершено.

Использование django-nonrel для аутентификации работает нормально. Основная проблема — это отношения «многие ко многим». Модуль аутентификации использует это для разрешений объекта пользователя - это не работает. Если вам это не нужно, вы, вероятно, могли бы вообще обойтись без использования SQL.

person dragonx    schedule 03.05.2012
comment
Я не мог заставить Django-nonrel работать, несмотря на то, что следовал букве множества источников документации. Это «в основном» там, в том, что у меня есть проект Django, и я почти даже могу заставить syncdb работать, но лучшее, что я получил, это запустить его до того, как он не сработает ... дерьмо, какая-то ошибка, связанная с ObjectID . Короче говоря, я остановился на mongoengine, который позволяет мне указать соединение в настройках, а также определить объекты класса, подобные Django, на которые я могу ссылаться. Ваш ответ не «сработал», но, поскольку вы нашли время хотя бы попробовать, я полагаю, что это чего-то стоит, поэтому он принят. - person bmelton; 05.05.2012

arrow_upward
0
arrow_downward

Добавление к ответу dragonx. Проблема с django-nonrel заключается в том, что модуль авторизации не работает.

Вы можете выполнять соединения «многие к маме» с помощью оператора $lookup. djongo делает это автоматически. Он переводит синтаксис SQL в запросы агрегации mongodb и заполняет объектную модель, как и другие драйверы SQL.

Модуль авторизации отлично работает на djongo.

person nesdis    schedule 17.08.2017