If you like Django’s ORM, it’s perfectly simple to use it “standalone”; I’ve written up several techniques for using parts of Django outside of a web context, and you’re free to use any of them (or roll your own).

Shane above seems to be a bit misinformed on this and a few other points — for example, Django can do multiple different databases, it just doesn’t default to that (you need to do a custom manager on the models which use something other than the “main” DB, something that’s not too hard and there are recipes floating around for it). It’s true that Django itself doesn’t do connection management/connection pooling, but personally I’ve always used external tools for that anyway (e.g., pgpool, which rocks harder than anything built in to an ORM ever could).

I’d suggest spending some time reading up and possibly trying a few likely Google searches (e.g., the post I linked you to comes up as the top result for “standalone Django script”) to get a feel for what will actually best suit your needs and tastes — it may be Django’s ORM isn’t right for you, and you shouldn’t use it if it isn’t, but unfortunately there’s a lot of misinformation out there which muddies the waters.

Editing to respond to Shane:

Again, you seem to be misinformed: SQLAlchemy needs to be configured (i.e., told what DB to use, how to connect, etc.) before you can run queries with it, so how is the fact that Django needs similar configuration (accomplished via your choice of methods — you do not need to have a full Django settings file) any disadvantage?

As for multiple DB support, you seem to be confused: the support is there at a low level. The query object — not QuerySet, but the underlying Query object it will execute knows what DB it’s connecting to, and accepts a DB connection as one of its initialization arguments. Telling one model to use one DB and another model to use another is as simple as setting up one method on a manager which passes the right connection info down into the Query. True, there’s no higher-level API for this, but that’s not the same as “no support” and not the same as “requires custom code” (unless you’d argue that configuring multiple DBs explicitly in SQLAlchemy, required if you want multiple DBs, is also “custom code”).

As for whether you end up indirectly using things that aren’t in django.db, well, so what? The fact that django.db imports bits of, say, django.utils because there are data structures and other bits of code which are useful for more than just an ORM is fine as far as I’m personally concerned; one might as well complain if something has external dependencies or makes use of standard Python libraries instead of being 100% self-contained.

(I’m reporting my solution because my question said to be a duplicate)

Ah ok I figured it out and will post the solutions for anyone attempting to do the same thing.

This solution assumes that you want to create new models.

First create a new folder to store your files. We’ll call it “standAlone”. Within “standAlone”, create the following files:

__init__.py
myScript.py
settings.py

Obviously “myScript.py” can be named whatever.

Next, create a directory for your models.

We’ll name our model directory “myApp”, but realize that this is a normal Django application within a project, as such, name it appropriately to the collection of models you are writing.

Within this directory create 2 files:

__init__.py
models.py

Your going to need a copy of manage.py from an either an existing Django project or you can just grab a copy from your Django install path:

django\conf\project_template\manage.py

Copy the manage.py to your /standAlone directory. Ok so you should now have the following structure:

\standAlone
    __init__.py
    myScript.py
    manage.py
    settings.py
\myApp
    __init__.py
    models.py

Add the following to your myScript.py file:

# settings.py
from django.conf import settings

settings.configure(
    DATABASE_ENGINE    = "postgresql_psycopg2",
    DATABASE_NAME      = "myDatabase",
    DATABASE_USER      = "myUsername",
    DATABASE_PASSWORD  = "myPassword",
    DATABASE_HOST      = "localhost",
    DATABASE_PORT      = "5432",
    INSTALLED_APPS     = ("myApp")
)

from django.db import models
from myApp.models import *

and add this to your settings.py file:

    DATABASE_ENGINE    = "postgresql_psycopg2"
    DATABASE_NAME      = "myDatabase"
    DATABASE_USER      = "myUsername"
    DATABASE_PASSWORD  = "myPassword"
    DATABASE_HOST      = "localhost"
    DATABASE_PORT      = "5432",
    INSTALLED_APPS     = ("myApp")

and finally your myApp/models.py:

# myApp/models.py
from django.db import models

class MyModel(models.Model):
     field = models.CharField(max_length=255)

and that’s it. Now to have Django manage your database, in command prompt navigate to our /standalone directory and run:

manage.py sql MyApp

You can certainly use various parts of Django in a stand-alone fashion. It is after-all just a collection of Python modules, which you can import to any other code you would like to use them.

I’d also recommend looking at SQL Alchemy if you are only after the ORM side of things.

I’m using django ORM without a settings file. Here’s how:

In the stand-alone app launcher file:

from django.conf import settings
from django.core.management import execute_from_command_line

#Django settings
settings.configure(DEBUG=False,
    DATABASES = {
        'default': {
            'ENGINE': 'django.db.backends.sqlite3',
            'NAME': '/path/to/dbfile',
            'USER': '',
            'PASSWORD': '',
            'HOST': '',
            'PORT': '',
        }
    },
    INSTALLED_APPS = ('modelsapp',)
)

if not os.path.exists('/path/to/dbfile'):
    sync = ['manage.py', 'syncdb']
    execute_from_command_line(sync)

Now you just need a ./modelsapp folder containing an __init__.py and a models.py. The config uses sqlite for simplicity sake, but it could use any of the db backends.

Folder structure:

./launcher.py
./modelsapp
    __init__.py
    models.py

Note that you don’t have to have a manage.py proper. The import execute_from_command_line just finds it.

Using Django 2.0 ORM – One File Required

from myproject.config import parse_config
from django import setup as django_setup
from django.conf import settings as django_settings

"""
Requirements:
  ODBC Driver: https://www.microsoft.com/en-ca/download/details.aspx?id=36434
  Django Engine: https://pypi.org/project/django-pyodbc-azure/
"""

config = parse_config()
django_settings.configure(
    DEBUG=True,
    DATABASES={
        'default': {
            'ENGINE': 'sql_server.pyodbc',
            'NAME': config.database_name,
            'HOST': config.database_server,  # exclude '\\MSSQLSERVER'
            'USER': config.database_username,
            'PASSWORD': config.database_password,
            'PORT': '',
            'AUTOCOMMIT': False,
            'OPTIONS': {
                'driver': 'ODBC Driver 11 for SQL Server',
            },
        },
    })
django_setup()


from django.db import models

class Foo(models.Model):
    name = models.CharField(max_length=25)

    class Meta:
        app_label = 'myapp'  # each model will require this

I recommend SQLAlchemy. It should do all the ORM stuff, as well as basic SQL stuff.

I understand this post is old, but in recent years I’ve found a smaller solution works great:

import os, sys
import django

# sys.path.append('/abs/path/to/my-project/)
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'project.settings')
django.setup()

# Use
from myapp import models
kv = models.KeyValue()

Ensuring this script runs in the applicable relative directory, or apply the sys PATH append to ensure the modules are resolved.

Hope it helps.

This example is as simple as it gets. I already have a django app called thab up and running. I want to use the django orm in free standing python scripts and use the same models as I’m using for web programming. Here is an example:

# nothing in my sys.path contains my django project files
import sys
sys.path.append('c:\\apython\\thab')  # location of django app (module) called thab          where my settings.py and models.py is
# my settings.py file is actualy in c:\apython\thab\thab
from thab import settings as s  # need it because my database setting are there
dbs = s.DATABASES
from django.conf import settings
settings.configure(DATABASES=dbs) # configure can only be called once
from thab.models import *
boards = Board.objects.all()
print 'all boards:' + str(boards) # show all the boards in my board table

Probably I’m quite late with my answer, but it’s better late than never.

Try this simple package:
https://github.com/serglopatin/django-models-standalone

How to use:

1. download

2. install

   python setup.py install
   

3. create project

   django-models-standalone startproject myproject
   

4. adjust files settings.py (DATABASES) and models.py, then migrate if tables not created

5. use djando models in your application (example.py)

import django
from django.conf import settings
from backend_mock.admin import settings as s
settings.configure(
    DATABASES=s.DATABASES,
    INSTALLED_APPS=('backend_mock.admin.mocker', )
)
django.setup()

take a look at this, it’s working for django version gte 1.8.x

This is what worked for me in Django > 1.4

Assuming that your standalone script is your django project DIR.

Just copy this in a conf.py file (you can give it any name).

import os
import sys
import django

BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
sys.path.append(BASE_DIR) 
#sys.path.append('c:\\apython\\thab')
 # location of django app (module) called thab          where my settings.py and models.py is
# my settings.py file is actualy in c:\apython\thab\thab
from elsaserver import settings as s  # need it because my database setting are there
dbs = s.DATABASES
from django.conf import settings
settings.configure(
    DATABASES=dbs,
    INSTALLED_APPS=('core.apps.CoreConfig', )) #add all the apps you need here
django.setup()

Then import the conf.py in your python script.

This is the project structure:

mydjangoproject
    |
    > app1
    > core
    > app2
    > standalone
    | | __init__.py  
    | | conf.py  
    | | myscript.py
    > manage.py

You can use it outside a django project.
But there are there things you should be aware of.

1. Multiple database router.

A router looks like:

class Router(object):
    app_label = ''

    def db_for_read(self, model, **hints):
        if model._meta.app_label == self.app_label:
            return self.app_label
        return None

    def db_for_write(self, model, **hints):
        if model._meta.app_label == self.app_label:
            return self.app_label
        return None

    def allow_relation(self, obj1, obj2, **hints):
        if obj1._meta.app_label == self.app_label or obj2._meta.app_label == self.app_label:
           return True
        return None

    def allow_migrate(self, db, app_label, model=None, **hints):
        if app_label == self.app_label:
            return db == self.app_label
    return None

You can use meta class to dynamic create router.

def add_db(db_conf):
    app_label = 'al_' + str(uuid4())

    settings.DATABASES[app_label] = db_conf

    router_class_name = 'Router' + app_label.capitalize()
    setattr(
        settings,
        router_class_name,
        type(router_class_name, (Router,), dict(app_label=app_label)),
    )
    settings.DATABASE_ROUTERS.append(
        '.'.join([settings.__name__, router_class_name])
    )
    connections.close_all()
return app_label

2. Django settings.

the most important key is TIME_ZONE. DatetimeField and DateField is releated to it.
A simplest setting should be:

SECRET_KEY = 'secret'
DATABASES = {'default': {}}
DATABASE_ROUTERS = []
TIME_ZONE = None

3. close_old_connections.

Django framework default run close_old_connections in every request middleware to avoid “mysql has gone away“.

PS: I have written package to use django orm not in a classic django project, https://github.com/jdxin0/django_db(https://github.com/jdxin0/django_db).
But you should always pay attention to the three problems above.My package use meta class to solve multi db, set TIME_ZONE=None and leave close_old_connections to user.