I want to use MongoDB as database backend for my Django project. Although there are many discussions on the net, I'm having troubles to integrate them well.
My goals:
use default Django (so no django-nonrel, which is still to 1.3)
integrate them so that authentication is backed by MongoDB (i.e. the
default User model) as well as the sessions thing.
if possible, still have a ORM-like query system
As I understand that, mongoengine could meet all my requirements, but I'm having troubles making it work correclty.
Docs say to ignore DATABASES setting. If I don't specify it, Django raises an error, while if I fill it, Django creates that database and does not use my MongoDB instance, even though I call connect() later in the file. When I run syncdb Django uses the other database (the one I specified in the DATABASES setting) and not MongoDB. So when I fire up MongoDB shell I can see the database is created, but the only collection is startup_log, which I never created and I suspect it's created automatically.
This might be a change in the default requirements does adding a dummy backend to your settings help?
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.dummy'
}
}
Related
I have a website that I built using Django and deployed on Heroku. The tutorial I followed had me set up a Heroku Postgres database attached as an add-on. After Heroku's recent pricing changes the Postgres database has gone from free to $5 / month.
Maybe static isn't the correct word, but the site doesn't have user accounts, collect user information, or otherwise have any need for a database. I believe the only information that's stored in the database is login info for the Django admin site. I was able to export a .pgdmp file from Heroku of the data stored in the database but couldn't make heads or tails of the contents.
Here's the settings.py file code for the database section:
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': BASE_DIR / 'db.sqlite3',
}
}
import dj_database_url
db_from_env = dj_database_url.config(conn_max_age=500)
DATABASES['default'].update(db_from_env)
My question is can I delete this add-on from the Heroku CLI or dashboard without breaking the site in production? Would I need to change anything in my settings.py file or elsewhere in my Django code first? I assume I would still be able to access the Django admin page on the development server, is that assumption correct?
Sorry for the possibly obvious question but I just don't want to break a site in production without doing some research first!
My question is can I delete this add-on from the Heroku CLI or dashboard without breaking the site in production?
We can't know for sure, but probably not.
You are using dj-database-url to set your default database. That likely means that your application is connecting to PostgreSQL via the DATABASE_URL environment variable.
SQLite does not work properly on Heroku due to its ephemeral filesystem. If you need a database, it needs to be a client-server database instead of a file-based database.
For anyone in my situation finding this in the future here's what I learned:
My initial hypothesis was correct, deleting the Postgres Heroku add-on left the site in production intact and working correctly. The only difference without the database is I can't access the Django admin page on the hosted site but I can still access this through the development server if needed.
Your site might be different than mine however, so your mileage may vary. Here's a couple things I did before making any changes to the site in production.
Check what tables/data you have in your database. Thanks to #Chris who answered in this thread and posted this link talking about the dataclips feature in Heroku. If you have tables that seem not to relate to the admin interface then you might be reliant on your database.
Consider spinning up another instance of your live site in production on Heroku. This way you can test and make changes without impacting users on the live site if something goes wrong.
I built a Django project with a few models. Now I created a second server with the same setup. This one is meant to be the deployment server. Databases are separate from the dev-server.
However can you tell me if I can simply copy the databases from the dev server to the deploy or will the Django logic, since I also mean the user models and permissions etc.
The tables which I created myself are no problem to transfer to the new server. However I am wondering If Django gets confused when I also transfer something like the auth_user Model.
Should this work since I also just copied the backend logic as well?
I'm using Django for backend, but for some reason, I want to use Laravel beside Django and share the database between them. so the same database for Django and Laravel. but the problem is that Django migrations are not equal to Laravel migrations so the database is different from ( for example constraints and indexes and some other options).
Is this going to break backend if I use Django as the primary database and use Laravel as a secondary backend?
If true, how I can use Django and Laravel in the same database?
Your database does not depend on Django or Laravel. It just stores data.
Constraints, triggers, indexes, etc are stored on the database itself, and they are completely independent of your framework. Frameworks just abstract the methods and provide easy methods to manage your database. At the core, they use the same commands which are provided by the database. The names of constraints are irrelevant, you can give whatever names you want, frameworks just provide their own uniform naming pattern, which can be customized by the user. So they can be used on both Django and Laravel or any other framework/programming language. That's the main purpose of having a database, to store data in a structured manner so it can be used by any language/framework
Since you already have migrations in Django, there's no need to create the migrations again in laravel. Just reuse the Django database and make your laravel application to properly handle the data (that part is completely in your control)
Im been looking at mongo-engine. From what I can see to allow you to use the ListField, DictField etc field types and to use the Django ORM style of db models (with a MongoDB) you need use django-nonrel/djangotoolbox (??)
Is there anyway to intergrate MongoDB with Django without using Django-norel.
I want to use django ORM, mongodb, listfield, dictfield whilst using my current django version.
Thanks,
You can use MongoEngine directly with Django; it does not use or require django-nonrel classes.
The MongoEngine documentation includes a full section on Django Support including Authentication, Custom User Models, Sessions, Storage, and Shortcuts.
Per the MongoEngine to Django connection instructions, you need to ignore the standard database settings (unless you also plan to use an ORM in your project), and instead call connect() somewhere in the settings module.
You also need to add a dummy database backend to your settings.py (if you are not using another database backend):
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.dummy'
}
}
I need to connect to a Postgresql server in my Django project. But I'm under strict instructions NOT to make any modifications to the database or tables.
If I'm not wrong, simply adding this DB to settings.py and running syncdb would create and add some django specific tables to the database.
How can I get around this issue? If I add another (local) sqlite DB to settings.py under default and my remote postresql server separately; can I be sure of Django not creating any tables in my server? I couldn't find this info in the documentation.
Thanks
Configure two databases in settings.py, and a create database router to route your queries to the appropriate database.
Route all the Django admin / users stuff to your sqlite database (make it the default database, and make sure that is indeed the one your router returns by default), and single out your application queries that need to go to the Postgres database.
Routers also have a method to locate a DB for writes and one for reads, so you can use this as a failsafe: just make sure db_for_write never returns your Postgres database, and you're good to go.