As I continue to work with Django, I am coming to appreciate the elegance and simplicity of its design. Less Ruby on Rails style “magic” gives us more flexibility. You can store your models any way you like. Last weekend, I played with the possibility of using Couchdb, and I found an example that seemed easy to understand. (Couchdb is another open source project that I may write about later.)
There should be two steps to plugging DB4O into Django. First, we should be able to store settings in the settings.py file to specify where and how we will be storing our objects. The second step should be to create and use our models almost exactly as we would in a regular Django application. It should be that easy.
Editing Settings
It is not my goal to duplicate information you can get elsewhere. To find out how to set up a Django project, and to understand the files that are created for you, see the following tutorials.
In this entry, we are going to look at how to use the setting file in Django to store settings for DB4O. You can store anything in the settings file you like, and you can store these settings in separate settings files named prodsettings.py, devsettings.py etc. These settings are easy to retrieve from views and models.
We are going to make the following assumptions in our example: we only have one settings file, and it is called settings.py. Also, we are persisting objects to a file, and we are not using an object server.
A cllient/server mode is available in DB4O, and we will have to provide for it later. (DB4O client/server mode is covered in Chapter 8 of the book, The Definitive Guide to db4o. The chapter about client/server mode is available for free, if you are curious.)
To create settings, find your settings file, called settings.py, and add values. To see what entries look like, see below:
# Django settings for mysite project.
DEBUG = True
TEMPLATE_DEBUG = DEBUG
ADMINS = (
# ('Your Name', 'your_email@domain.com'),
)
MANAGERS = ADMINS
DATABASE_ENGINE = ''
DATABASE_NAME = '/path/to/file.db4o'
DATABASE_USER = '' # Not used with db4o in file mode.
DATABASE_PASSWORD = '' # Not used with db4o in file mode.
DATABASE_HOST = '' # Not used with db4o in file mode.
# Local time zone for this installation. Choices can be found here:
# http://en.wikipedia.org/wiki/List_of_tz_zones_by_name
# although not all choices may be available on all operating systems.
# If running in a Windows environment this must be set to the same as your
# system time zone.
TIME_ZONE = 'America/Chicago'
# Language code for this installation. All choices can be found here:
# http://www.i18nguy.com/unicode/language-identifiers.html
LANGUAGE_CODE = 'en-us'
. . . . . . .
For our purposes, DATABASE_NAME will be the name of the file used by DB4O to persist objects. If you have read the DB4O documentation, you will know that you also have the option of running a server, in which case we could also use the DATABASE_HOST and DATABASE_PORT settings.
We also have the option of creating any settings we want to help us manage our application’s behavior. Django’s convention is to use capital letters for settings and to separate words with underscores.
At this point, we have enough information to find and connect to our DB4O file and we have stored it in the settings file. These settings will be used by our models to create objects and manage them. Our models will be written in such a way as to hide DB4O specific details from programmers. In my next installment, I will think about how to create a model for us to use with DB4O running in Django/Jython.
My thinking is that I will create my models in Jython, but I will create a command line script to create plain old Java objects (POJOs) and place them in a jar for us. I am lazy, and I always use Eclipse to create my jars for me. I expect to face some challenges at the command line, but I am up for it.
Therefore, the steps will be:
The only difference will be in the behavior of the models, but our goal will be not to violate too many expectations. Regular Django models subclass django.db.models.Model, but ours will subclass DB4OModel, a class we will create. Our DB4O should resemble Django models as much as possible.
In my next installment, let’s look at DB4OModel. What does it need to look like?
Thanks for this blog. I am new at development and this will be a big help.