{"id":7141,"date":"2013-01-28T07:00:07","date_gmt":"2013-01-28T07:00:07","guid":{"rendered":"http:\/\/vskills.in\/certification\/tutorial\/?p=7141"},"modified":"2024-04-12T14:17:09","modified_gmt":"2024-04-12T08:47:09","slug":"interacting-with-a-database-models","status":"publish","type":"page","link":"https:\/\/www.vskills.in\/certification\/tutorial\/interacting-with-a-database-models\/","title":{"rendered":"Interacting with a Database: Models"},"content":{"rendered":"

Certify and Increase Opportunity.<\/span>
\nBe <\/span>
\nGovt. Certified Django Developer
\n<\/span><\/a><\/p>\n

Interacting with a Database: Models<\/p>\n

Django Integration<\/h1>\n

New in version 0.9.2.<\/p>\n

These functions streamline the process of initializing Django\u2019s settings module environment variable. Once this is done, your fabfile may import from your Django project, or Django itself, without requiring the use of manage.py<\/tt> plugins or having to set the environment variable yourself every time you use your fabfile.<\/p>\n

Currently, these functions only allow Fabric to interact with local-to-your-fabfile Django installations. This is not as limiting as it sounds; for example, you can use Fabric as a remote \u201cbuild\u201d tool as well as using it locally. Imagine the following fabfile:<\/p>\n

\n
\n
from fabric.api import run, local, hosts, cd\nfrom fabric.contrib import django\n\ndjango.project('myproject')\nfrom myproject.myapp.models import MyModel\n\ndef print_instances():\n    for instance in MyModel.objects.all():\n        print(instance)\n\n@hosts('production-server')\ndef print_production_instances():\n    with cd('\/path\/to\/myproject'):\n        run('fab print_instances')<\/pre>\n<\/div>\n<\/div>\n
With Fabric installed on both ends, you could execute print_production_instances<\/tt> locally, which would trigger print_instances<\/tt> on the production server \u2013 which would then be interacting with your production Django database.<\/p>\n
As another example, if your local and remote settings are similar, you can use it to obtain e.g. your database settings, and then use those when executing a remote (non-Fabric) command. This would allow you some degree of freedom even if Fabric is only installed locally:<\/p>\n
\n
\n
from fabric.api import run\nfrom fabric.contrib import django\n\ndjango.settings_module('myproject.settings')\nfrom django.conf import settings\n\ndef dump_production_database():\n    run('mysqldump -u %s -p=%s %s > \/tmp\/prod-db.sql' % (\n        settings.DATABASE_USER,\n        settings.DATABASE_PASSWORD,\n        settings.DATABASE_NAME\n    ))<\/pre>\n<\/div>\n<\/div>\n
The above snippet will work if run from a local, development environment, again provided your localsettings.py<\/tt> mirrors your remote one in terms of database connection info.<\/p>\n
\n
fabric.contrib.django.<\/tt>project<\/tt>(<\/big>name<\/em>)<\/big><\/dt>\n
Sets DJANGO_SETTINGS_MODULE<\/tt> to '<name>.settings'<\/tt>.This function provides a handy shortcut for the common case where one is using the Django default naming convention for their settings file and location.<\/p>\n
Uses settings_module<\/tt> \u2013 see its documentation for details on why and how to use this functionality.<\/dd>\n<\/dl>\n
\n
fabric.contrib.django.<\/tt>settings_module<\/tt>(<\/big>module<\/em>)<\/big><\/dt>\n
Set DJANGO_SETTINGS_MODULE<\/tt> shell environment variable to module<\/tt>.Due to how Django works, imports from Django or a Django project will fail unless the shell environment variable DJANGO_SETTINGS_MODULE<\/tt> is correctly set (see the Django settings docs.)<\/p>\n
This function provides a shortcut for doing so; call it near the top of your fabfile or Fabric-using code, after which point any Django imports should work correctly.<\/p>\n
Models<\/h1>\n
model is the single, definitive source of data about your data. It contains the essential fields and behaviors of the data you\u2019re storing. Generally, each model maps to a single database table.<\/p>\n
The basics:<\/p>\n