Django-nonrel срещу Django-mongodb срещу Mongokit срещу pymongo native

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

В идеалния случай бих искал да запазя SQL магазина за простите неща, потребителско удостоверяване, групи и т.н., и да използвам Mongo за по-големите данни.

Бих искал също да имам моите съхранени в Mongo обекти като класове, в стил Django-ORM, така че да мога да имам подобно „усещане“, но това не е критично.

И накрая, позволява ли ми някое от изброените по-горе да използвам поддръжката на множество бази данни на Django за каквото и да било, или всичките ми mongo заявки са ефективно „извън групата“ от Django ORM?

Ако има някакви други фактори, които пропускам и които може да са важни, не се колебайте да ме насочите. Знам малко на тази сцена.


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)


Django-nonrel е правилният начин за Django в MongoDB. Има django-mongodb.org, но той просто е изграден върху Django-nonrel. Има доста активност на mongodb в пощенския списък на django-nonrel.

Съхраняването на вашите mongo класове като 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

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

Можете да извършвате много-към-мама присъединявания, като използвате $lookup оператор. djongo го прави автоматично вместо вас. Той превежда SQL синтаксиса в заявки за агрегиране на mongodb и попълва обектния модел, подобно на други SQL драйвери.

Модулът за удостоверяване работи добре на djongo

person nesdis    schedule 17.08.2017