For few days I have been searching for a tutorial that shows how MongoDB can be used as a database with Django but resulted in nothing fruitful or clear tutorial. There have been questions regarding this in this forum most of them directed to look up for http://www.django-mongodb.org/ but I find there's something else written. Can anybody suggest me some good tutorial or pointers where I can start with.
P.S. I myself have searched a lot but couldn't find anything that tells the whole procedure.
The main options tu use MongoDB with Django are:
MongoEngine is an ORM for MongoDB with some Django Integration. This will not replace the Django ORM, but you're free not to use it.
Django MongoDB Engine provides a tighter intgration in Django by providing a MongoDB backend to the Django ORM, but requires the use of Django-nonrel, a fork of Django that adds support for non-relational databases.
The Django MongoDB Engine documentation formerly known as http://www.django-mongodb.org/ is now available at https://django-mongodb-engine.readthedocs.org/. For future reference, you can get the previous version of the site using the Internet Archive's Wayback Machine.
Related
I am new to cloudantdb and django. Is there any way to integrate cloudantdb with danjgo framework. Is it possible to connect cloudant with django?
As you may be aware, Cloudant is built on Apache CouchDB, so if you can't find references for Cloudant, it's usually worth also searching for CouchDB. I don't really use Django, but a quick search throws up the following references:
http://leok.me/2013/05/02/what-you-need-to-know-couchdb-django/
https://lethain.com/an-introduction-to-using-couchdb-with-django/
http://eflorenzano.com/blog/2008/11/10/using-couchdb-django/
https://djangopackages.org/grids/g/couchdb/
Most if not all solutions on the web are very outdated.
The solution used by IBM in a capstone project on Coursera was:
Use SQLite backend in your Django app
Create Cloud Functions for communicating with Cloudant
Create REST API definitions in your Django app that utilize the Cloud Functions to communicate with Cloudant
I don't know if it's the best solution, but it works. I do feel like SQLite is redundant at this point but without it, I couldn't get the app to work.
This question is already asked on StackOverflow,
The asked questions date back to 2013, Its 2015 now and Django has grown up fast.
What is the situation of using mongodb with Django 1.8 as of 2015?
Does Django support Monogodb out of the box (with db adapters)? or another distribution like django-nonrel should be used?
I don't think Django provides out of the box support for MongoDB. It is more tailored for relational databases.
One solution could be using MongoEngine.
MongoEngine is an Object-Document Mapper, written in Python for
working with MongoDB.
You need to just configure MongoEngine with Django and then it should work comfortably.
just my thoughts and somewhat subjective and opinionated but I would say it does not work very well. I quickly disbanded the idea of trying to run Django with MongoDB, since it's auth system is heavily reliant upon a relational database to work.
There are apparently ways around this, but ultimately I decided for my project it was not worth the effort just to use MongoDB.
Does Django support Monogodb out of the box (with db adapters)?
No, it does not. If you can find a django compatible engine for mongodb, then it will work perfectly.
The good news is there is such an engine, called django-mongodb-engine; the bad news is that it relies on django-nonrel which is not updated against the latest stable version of django.
So, if you must - you can use MongoDB at the expense of not having some updated django features available to you (and more importantly, any security patches).
If you want to supplement your main database with mongodb - that is, mongodb will not be your primary database, then the process is a lot easier.
So, in summary:
django 1.8 provides no out-of-the-box support for mongodb (or other non-relational databases) as the primary data store.
support is available using the third party django-nonrel package, which is behind the current django production version.
I came across a new package that does support the latest django on MongoDB: djongo
As stated above, mongoengine does not support all contrib apps of django. Especially the auth app doesn' work on mongoengine
Djongo claims to compile SQL queries into mongodb queries. So its is essentially version agnostic and works for all versions of Django.
Disclosure: I have contributed to this package by making minor bug fixes.
I know that its been three years but for those who are wondering about MongoDB and Django now should know that the situation has not changed. Mongoengine as described earlier is a good enough tool but still there are limitations. For instance when i integrated mongodb with django using mongoengine i was not able the use elastic search with my application. Furthermore with mongoDB you loose you loose Django admin and authentications functionalities. So, MongoDB with Django is still a risky choice
I have started a month ago with GAE and have successfully deployed our current startup via Flask on GAE. It works fantastically well. Now being all too exited about GAE, I am thinking about porting a couple of my older Django apps on GAE as well.
To my surprise the documentation of it is surprisingly inconsistent and partially contradicting.
The official google page recommends using django-nonrel, which itself is already disconstinued.
Django 1.5.1 seems not even to be supported yet on GAE, neither is it clear to me how to use Django 1.4.3 on GAE.
I also found this more recent solution that utilizes Django and Google Cloud (Mysql on cloud) instead of the high replication datastore. Not sure if this is a good way to go since its still experimental and subject to "breaking changes" in future. (It also doesn't seem to include any free tier, unlike high replication datastore)
I was expecting Django - as perhaps the biggest python web frameworks - to have a far better documentation or tutorials about how to do deploy it on GAE. So I wonder if its even worth it sticking with Django on GAE anymore.
If I am meant to make manually my own models and adjust my queries in Views by utilizing ndb anyway, I could as well stick with flask+Jinja2, why should I use Django, where I can't even use it's ORM anymore? Or am I overlooking something?
Thanks,
There's nothing on the link to the allbuttonspressed blog that implies it is discontinued. On the contrary, the page says that even though they (as the original maintainers) are pulling out of the project, it has been taken over by a new maintainer. That's what often happens in open-source projects.
As for Cloud SQL, there is a dedicated page on the App Engine documentation which explains in detail how to get this up and running. The Cloud SQL API itself is, it's true, still in "experimental" status, but again that's just what Google does. App Engine itself only came out of "experimental" last year.
As for why you should stick with Django, that's up to you of course, but both of the above solutions will give you Django forms, the admin interface, templates, and URL routing, and some or all of the ORM syntax.
There's some work going on in maintaining django-nonrel, though the Allbuttonspressed blog is starting to get pretty out of date. You'll find more up-to-date info in the django-nonrel mailing list on Google Groups.
I believe it's been updated to at least Django 1.5, but I'm personally still running on 1.4. The documentation is extremely lacking. You'll have to figure out from the mailing list the appropriate branch to use to get support for the latest django version. However, it's there and it's working.
Django + CloudSQL will likely be the least-coding route to port your app to GAE.
Django-nonrel gets to take advantage of the HRD, however, many apps written expecting SQL behavior will need to be extensively rewritten to support the HRD behavior properly.
As an example, I've tried running django-registration on django-nonrel. On first look, it seems to work fine. But on deeper inspection, there's issues like being able to register the same email address to more than one user on HRD. You may find similar issues with other apps, or just the inability to run at all, given that the HRD doesn't support many-to-many relations, as well as slightly-more-complex queries.
I am trying to build a DB system using Django as the framework and MongoDB for my database management system. How can I add things to a specific collection? Where should I specify the name of the collection?
Then, after I have added to the collection, how can I use a Django shell to ask for that information from Mongo?
You don't "add a collection" on MongoDB -- you just use them. In Django - MongoDB: (could not connect to localhost:27017) Connection refused you already got Django MongoDB Engine running, so I don't understand your question? You can use the Django ORM to get data into and out of MongoDB now.
There are many good tutorials of using mongodb with Django. One popular way is to use django-mongodb which integrates to django models. Here is their tutorial.
Another screencast: Integrating mongoDB and Django.
I am looking for a guide to migrate Django project to Google App Engine and use Google's datastore. The most of the guides I found were linked to Django-Appengine using Django-nonrel (but I want to use GAE's native support).
Going through GAE getting started guide, it says:
Google App Engine supports any framework written in pure Python that speaks CGI (and any WSGI-compliant framework using a CGI adaptor), including Django, CherryPy, Pylons, web.py, and web2py. You can bundle a framework of your choosing with your application code by copying its code into your application directory.
I understand that I won't be able to use some features of Django in that case (majorly the admin feature) and would also need to restructure the models.
From other reading, I also found that latest SDK of GAE now includes Django 1.3 on Python 2.5.
I tried to put all files from my Django application to a GAE project, but couldn't get it all to work together.
Please provide some basic guide using which I may migrate my Django project to Google App Engine's code.
Thanks.
For an existing Django app, using django-nonrel is the simplest approach; it is very popular so you should be able to find help with specific errors you get quickly.
Another approach is written up in this article: http://code.google.com/appengine/articles/pure_django.html -- it goes the other way, taking an App Engine app that uses Django for dispatch, templates, and forms, but not for models, and describes how to make it run in a native Django environment. Maybe you can glean some useful hints for your situation from it.
I've used django-nonrel, which behaves pretty much like django, except that operations with JOINs will return errors. I've basically worked around this by avoiding ManyToMany fields, and essentially building that functionality manually with an intermediate table.
So far I've ran into two problems with Django-nonrel:
1. No access to ancestor queries, which can be run in a transaction. There's a pending pull request for this feature though.
2. You can't specify fields that are not indexed. This could significantly increase your write costs. I have an idea to fix this, but I haven't done so yet.
(Edit: You CAN specify fields that are not indexed, and I've verified this works well).
2 (new). Google is pushing a new database backend called ndb that does automatic caching and batching, which will not be available with django-nonrel.
If you decide not to use django-nonrel, the main differences are that Django models do not run under App Engine. You'll have to rewrite your models to inherit from App Engine's db.Model. Your forms that use Django's ModelForm will need to inherit from google.appengine.ext.db.djangoforms instead. Once you're on App Engine, you'd have to port back Django if you ever take your app somewher else.
If you already have a Django application you might want to check this out. You won't work with App Engine's datastore but Google Cloud SQL might fit your needs.