This is a pre-production deployment of Warehouse, however changes made here WILL affect the production instance of PyPI.
Latest Version Dependencies status unknown Test status unknown Test coverage unknown
Project Description
This fork contains compatibility updates required to play nice with django-grappelli.
Original lazybird's Django-Solo README is left unchanged bellow.

Django Solo

| |
| |
| \ | Django Solo helps working with singletons:
| /\ | database tables that only have one row.
| >=)'> | Singletons are useful for things like global
| \/ | settings that you want to edit from the admin
| / | instead of having them in Django
| |
| |


Solo helps you enforce instantiating only one instance of a model in django.

* You define the model that will hold your singleton object.
* django-solo gives helper parent class for your model and the admin classes.
* You get an admin interface that's aware you only have one object.
* You can retrieve the object from templates.
* By enabling caching, the database is not queried intensively.

Use Cases

Django Solo is also great for use with singleton objects that have a one to many relationship. Like the use case below where you have a 'Home Slider" that has many "Slides".

* Global or default settings
* An image slider that has many slides
* A page section that has sub-sections
* A team bio with many team members

There are many cases where it makes sense for the parent in a one to many relationship to be limited to a single instance.

Usage Example


from django.db import models
from solo.models import SingletonModel

class SiteConfiguration(SingletonModel):
site_name = models.CharField(max_length=255, default='Site Name')
maintenance_mode = models.BooleanField(default=False)

def __unicode__(self):
return u"Site Configuration"

class Meta:
verbose_name = "Site Configuration"


from django.contrib import admin
from solo.admin import SingletonModelAdmin
from config.models import SiteConfiguration, SingletonModelAdmin)

# There is only one item in the table, you can get it this way:
from .models import SiteConfiguration
config = SiteConfiguration.objects.get()

# get_solo will create the item if it does not already exist
config = SiteConfiguration.get_solo()

In your model, note how you did not have to provide a `verbose_name_plural` field -
That's because Django Solo uses the `verbose_name` instead.


This application requires Django >= 1.4.

Just install the package using `pip install django-solo` and add ``solo`` to
your ``INSTALLED_APPS`` setting.

This is how you run tests:

./ test solo --settings=solo.tests.settings


The standard Django admin does not fit well when working with singleton,
for instance, if you need some global site settings to be edited in the admin.
Django Solo provides a modified admin for that.

![django-solo admin]( "django-solo admin")

* In the admin home page where all applications are listed, we have a `config`
application that holds a singleton model for site configuration.
* The configuration object can only be changed, there's no link for "add" (1).
* The link to the configuration page (2) directly goes to the form page - no
need for an intermediary object list page, since there's only one object.
* The edit page has a modified breadcrumb (3) to avoid linking to the
intermediary object list page.
* From the edit page, we cannot delete the object (4) nor can we add a new one (5).

Availability from templates

The singleton object can be retrieved from template by giving the Django model
dotted path:

{% get_solo 'app_label.ModelName' as my_config %}


{% load solo_tags %}
{% get_solo 'config.SiteConfiguration' as site_config %}
{{ site_config.site_name }}
{{ site_config.maintenance_mode }}


By default caching is disabled: every time `get_solo` retrieves the singleton
object, there will be a database query.

You can enable caching to only query the database when initially retrieving the
object. The cache will also be updated when updates are made from the admin.

The cache timeout is controlled via the `SOLO_CACHE_TIMEOUT` settings.
The cache backend to be used is controlled via the `SOLO_CACHE` settings.


### Template Tag Name

You can retrieve your singleton object in templates using the `get_solo`
template tag.

You can change the name `get_solo` using the


### Cache backend

Django provides a way to define multiple cache backends with the `CACHES`
settings. If you want the singleton object to be cached separately, you
could define the `CACHES` and the `SOLO_CACHE` settings like this:

'default': {
'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
'local': {
'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',

SOLO_CACHE = 'local'

Caching will be disabled if set to `None`.

### Cache timeout

The cache timeout in seconds.

SOLO_CACHE_TIMEOUT = 60*5 # 5 mins

### Cache prefix

The prefix to use for the cache key.


Getting the code

The code is hosted at

Check out the latest development version anonymously with::

$ git clone git://
Release History

Release History


This version

History Node

TODO: Figure out how to actually get changelog content.

Changelog content for this version goes here.

Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Show More

Download Files

Download Files

TODO: Brief introduction on what you do with files - including link to relevant help section.

File Name & Checksum SHA256 Checksum Help Version File Type Upload Date
django-solo-grappelli-1.1.1.tar.gz (7.5 kB) Copy SHA256 Checksum SHA256 Source Sep 19, 2015

Supported By

WebFaction WebFaction Technical Writing Elastic Elastic Search Pingdom Pingdom Monitoring Dyn Dyn DNS HPE HPE Development Sentry Sentry Error Logging CloudAMQP CloudAMQP RabbitMQ Heroku Heroku PaaS Kabu Creative Kabu Creative UX & Design Fastly Fastly CDN DigiCert DigiCert EV Certificate Rackspace Rackspace Cloud Servers DreamHost DreamHost Log Hosting