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?
Jim Huginin, the founder the Jython project, is credited with having said: “The purpose of a programming language is to let software developers express their intentions as simply and directly as possible.”
Unfortunately, we computer programmers are cursed by their own understanding of complexity. In fact, non-programmers often think complexity is a fundamental measure of our skill. The truth is that complexity is easier to achieve than simplicity. Simplicity is the Holy Grail of any framework or programming language.
I aspire to developing code that clearly and simply expresses my intentions. Simplicity is in the eye of the beholder, of course. Often, one paints oneself into a corner and then simplicity goes out the window. However, we am starting from scratch here, so let’s be hopeful.
My site stats indicate that few people have paid attention to the articles I posted by Dhananjay Nene. As I continue working with DB4O, I hope you get a chance to read these articles, especially the code examples.
The Project
For anyone who is jumping in late, the latest version of Jython, a version of Python that has been implement on the JVM, supports Django, a framework similar to Ruby on Rails. I want to demonstrate how to build a website, using Django to manage controllers and views, but I want to manage my models using DB4O.
Since I started writing about DB4O, my site has been getting visitors from about 50 different countries. But, there are few visitors from my own country, Canada. I find that interesting.
This Week
Django lets you replace parts of the framework very easily. In fact, I am quickly coming to appreciate this flexibility when I compare Django to other frameworks. Django does not force you to use its templating system, nor does it for you to use its data models. This is the flexibility we want to exploit to get DB4O working happily with Dajngo running on Jython.
This week, I want to concentrate on hiding DB40 from programmers who want to use DB4O to persist objects while using Django/Jython. The objects should save themselves, and the details should be administered from a central file. This is where I hope to get the most help from Jython as opposed to Java.
A Small Task
While I do this work, if anybody is interested in helping out, here is a task. I have managed to install Nginx on a server, and I have Django under Nginx running using FastCGI and regular Python, not Jython. To do this, I had to install Flup. My question is: can we install Flup under Jython? I would be happy to chat with anybody who either knows the answer, or is willing to investigate.
Otherwise, we will have to find another way – we could run Django in a servlet, and we could perhaps use Jetty. Any other options?
Why Jython?
As programming languages go, Python is beautiful, elegant, fun, powerful, concise, and easy to learn. Python is written in C, but Jython is a version of Python that is written in Java. This means that you can write a program using Python, which has all of the niceness of Python, but also has access to class libraries that are available in Java. Remember, Java is both a language and a platform, which supports many other languages, including Ruby, Lua, and many others.
Python is popular, and widely used. It comes installed on the vast majority of popular Linux distributions. It runs on Windows. And, and the latest version of Jython not only allows you to use Java libraries, but it also allows you to use popular Python based frameworks like Django, a Python based alternative to Ruby on Rails.
The development of Jython is being undertaken by Sun, which bodes well for its future development.
Why DB4O?
After years of using databases any time I needed to persist information, I have finally rejected that appraoch. One day, will working with an elaborate library of objects that hid the database from programmers, I realized that it would be a lot less work if I could just persist the objects as-is. My code would look pretty well the same, but I would not have to maintain a web server or write stored procedures.
Less work is always a good thing, especially if you lose nothing in the process. DB4O is fast, and it saves objects to the file system – that’s just what I thought I needed. I looked at other products, but DB4O is the leader as far as I am concerned.
Why DB4O and Jython?
There are many reasons. One is that Jython allows you to write less code and to be more productive. Another is that it is not possible to use DB40 with Python unless you willing to use Jython.
Personally, I am attacted to the idea of using DB4O to persist objects with the Django framework. Django, an alternative to Ruby on Rails, will run on Jython. I do not anticipate being able to find the time to dig in to this problem. What would be required is an Active Record like wrapper around DB4O. I would be inclined to develop something that looks as much like Django’s data modelling framework as possible.
The first thing to be aware of is that DB4O persists Java objects, but it does not persist Python objects. Therefore, as you use DB4O with Jython, you need to define the classes you want to persist in Java. I usually put these classes in a JAR, and place them in my Jython classpath.
In an upcoming blog entry, I will use some of the DB4O samples and implement then in Jython. I will show you how to define the classes and create JARs using the Eclipse IDE. You can use Netbeans if you like, but I only have time to provide examples using the tools I commonly use.
Then I will show you how to use Jython to work with objects that have been persisted using DB4O. I hope to show you that you can do this in less time using Jython because you are writing less code. Where I can, I hope to showcase the features of Python that can make working with DB4O more fun.
Join In, If You Wish
If you become interested in these examples, please feel free to correct me or to offer better solutions. I will be sure to give you the credit. If you decide to extend Django for Jython using DB4O, I will participate where I can and provide whatever help I can. I can provide some space on a server for a web site, but you have many other options.