This application requires, and depends upon Django being installed. Only Django 1.7 and above is supported, but if you are still using 1.7 then you really should upgrade!
Installation and Configuration¶
Install it using your favourite installer: mine is pip:
pip install django-boardinghouse
You will need to add
boardinghouse to your
You will need to use the provided database engine in your
You will need to add the provided middleware to your
You will probably also want to install the context processor:
Where this needs to go depends on your version of django: in 1.8 and newer it goes in
settings.TEMPLATES...['context_processors']. In older versions, it goes in
If you have the admin installed, it adds a column to the admin
django.contrib.admin.models.LogEntry class, to store the object schema when applicable.
It’s probably much easier to start using
django-boardinghouse right from the beginning of a project: trying to split an existing database may be possible, but is not supported at this stage.
By default, the model
boardinghouse.models.Schema will be used for the object representing the schemata, however you may override this by using the setting
settings.BOARDINGHOUSE_SCHEMA_MODEL. You’ll probably want to subclass
django-boardinghouse has been installed, it will override the following commands:
This replaces the
loaddata command with one that takes a new
--schema. This is required when non-shared-models are
included in the file(s) to be loaded, and the schema with this name
will be used as a target.
--schema option is supplied, that schema is used for the
source of the data. If it is not supplied, then the
schema will be used (which will not contain any data).
If any models are supplied as arguments (using the
notation) that are not shared models, it is an error to fail to pass a schema.
The included middleware must be installed:
Middleware to set the postgres schema for the current request’s session.
The schema that will be used is stored in the session. A lookup will occur (but this could easily be cached) on each request.
There are three ways to change the schema as part of a request.
Request a page with a querystring containg a
The schema will be changed (or cleared, if this user cannot view that schema), and the page will be re-loaded (if it was a GET). This method of changing schema allows you to have a link that changes the current schema and then loads the data with the new schema active.
It is used within the admin for having a link to data from an arbitrary schema in the
This type of schema change request should not be done with a POST request.
This will not cause a redirect to the same page without query string. It is the only way to do a schema change within a POST request, but could be used for any request type.
Add a request header:
This is designed to be used from AJAX requests, or as part of an API call, as it returns a status code (and a short message) about the schema change request. If you were storing local data, and did one of these, you are probably going to have to invalidate much of that.
Use a specific request:
You could also come up with other methods.
You will probably want to install the context processor: this will ensure that there is always a context variable
A Django context_processor that provides access to the logged-in user’s visible schemata, and selected schema.
Adds the following variables to the context:schemata: all available schemata this user has schema_choices: (schema, name) pairs of available schemata selected_schema: the currenly selected schema name