If you are impatient, like me, follow the steps I outline below, and you can stop reading here.

First things first: get the book. You can purchase the PDF of the Definitive Guide to Jython by clicking on the image of the book that appears above. Or, you can view a preview that is available at Google Books.

Last, but not least, there is also an open source version of the book. I will refer to this version in my examples, but, if you own the book, follow along.

I suggest that you download Aptana and install PyDev – that is the IDE I will be using in my examples. Since Aptana is based on Eclipse, you also have the option of installing the PyDev plugin in your current Eclipse Install.

I am going to assume that you have Java running on your machine, but I will provide instructions for the other steps. So, just to keep things easy, to get started follow these steps:

Get the software.

1. Install Jython on your machine.
2. Get Pydev running on your machine. (As part of Aptana, or as an Eclipse plugin.)
3. Get the latest version of DB4O for Java.

Bookmark the useful resources:

1. The Definitive Guide to Jython
2. The PyDev Documentation
3. The DB4O Documentation

You are free to bookmark these resources any way you please, but I am fond of Delicious because I can access my links from anywhere, because there is a Delicious API and because there are some cool plugins for Firefox and Google Chrome that make it more fun to use the service.

Get this done, and move on to part 2 when I have written it.

So far, in tutorials I wrote in November of last year, we have seen that Jython allows us to write Python code that uses Java libraries, such as DB40. I altered the standard DB4O Formula One tutorial using Jython instead of Java, and showed that we can persist and retrieve objects using this technology.

I also mentioned that Django, a Python based web application framework, also runs on Jython.

Which leads us to this entry, where I will start thinking and tinkering to find a way to use DB4O with Django/Jython rather than a relational database.

I am doing this for fun, not for profit. I am not an expert with any of the technologies I am using. I stand in awe of the very talented open source programmers who precede me. I hope to learn as much as I hope to teach and share what I know, or think I know.

Persisting Objects:

In my previous example, I created Plain Old Java Objects (Pojos), and created a JAR. I used the classes in the JAR to create the objects I persisted using DB4O. I have since decided that this is not desirable. I think this creates a barrier to Python programmers who want to use Django, Python and DB4O togther.

Therefore, I have resolved to persist Python classes by providing the means to automagically inspect these classes and generate the JAR files. I shared these thoughts over a month ago.

Before writing any code, I just want to reflect on the task at hand. Let’s gather our assumptions.

• For every Python data type, there is a corresponding Java data type.
• A “simple” object is based on a class that contains primitive types only.
• A complex object contains other objects, or collections of objects.
• We may need to make two passes to persist objects – first simple objects, and then complex.
• A class contains an implementation as well as data, and we want to persist both.
• If we change the definition of a class in our project, we need to think about what happens to our previously stored objects.
• Our Jython classes must inherit from a single class only, or we will not be able to produce an equivalent Java class.

In Django, we define models, and then use a command (python manage.py syncdb) to generate the corresponding database. The database is created automagically, based on the settings in the settings file (settings.py). The model is able to perform basic operations to create, read, update and delete objects (CRUD).

We want our DB4O objects to behave in the same way – as much as possible, we do not want to violate the expectations of Django programmers who have used Django with relational databases.

In my next entry, I will try to write code that creates a Java class based on a Jython class and saves it in a file. I will keep it simple to start, and the code will evolve as we go.

Our first model will be simple – a class with a few attributes of various types. The output will be a class files – we will not worry about creating the JAR just yet.

Once we have produced a simple class file, we will produce class that make two passes and resolve inheritance issues as well as contained objects that inherit from previously defined classes.

Code to come in a day or two.

I live in Ottawa, Canada. We are currently experiencing a bus strike – traffic is a nightmare. Some people are reporting that it it is taking up to four times longer to get to work and home. My experience is similar. Combine that with the Christmas season, and my time for blogging and coding is drastically reduced.

Still, I can see that many of you continue to visit. You are eagarly waiting for continued information on my progress with DB4O and Django running in Jython. Last month, I received blog visits from 411 cities in 69 different countries.  I am proud to report that 57% of you are using the Firefox browser – only 21% are using Internet Explorer. As an aside, I was surprised to see that 6% of you are using Chrome.

So, my friends, if you can forgive me – I will contnue the work soon. And, I am sorry for not blogging. All the best. I am not writing, but I am developing and tinkering – the work continues.

If you like what Java has to offer in terms of class libraries, but you like the Python language and its idioms, then Jython is the best of both worlds.

To prepare for my next installments on Jython, Django and DB4O, read about introspection in Python.

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:

1. Create models in a file called models.py.
2. Run a command line command to generate a jar that contains classes for the the Java objects we want to persist. This jar will need to be in Jython’s classpath when the application runs. Corresponds to python manage.py syncdb for regular Django models.
3. Build views, and use Django just as you would to create any other Django application.

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?

Also, some of you will be think about Jython performance. Performance is not everything, but if that is what you care about, then Dhananjay Nene has written this excellent article to help you understand where Jython stands compared to other languages and implementations, including Ruby. (Be sure to note that Python produces the fewest lines of code.)

In our second installment, we used Jython to retrieve the objects we save in the first part of the tutorial. Now, we need to update and delete these objects.

Then we will have learned how to perform the four basic functions of persistent storage: create, retrieve, update and delete – often referred to as CRUD

This tutorial is based on the Formula One DB4O tutorial.

Updating objects

Updating objects is just as easy as storing them. In fact, you use the same set() method to update your objects: just call set() again after modifying any object.

Java Code:

    // updatePilot
    ObjectSet result=db.get(new Pilot("Michael Schumacher",0));
    Pilot found=(Pilot)result.next();
    found.addPoints(11);
    db.set(found);
    System.out.println("Added 11 points for "+found);
    retrieveAllPilots(db);

   OUTPUT:
    Added 11 points for Michael Schumacher/111
    2
    Michael Schumacher/111
    Rubens Barrichello/99

Jython Code:

    result=db.get(Pilot("Michael Schumacher",0))
    found=result.next()
    found.addPoints(11)
    db.set(found)
    print "Added 11 points for "+found
    retrieveAllPilots(db)

Notice that we query for the object first. This is an important point. When you call set() to modify a stored object, if the object is not ‘known’ (having been previously stored or retrieved during the current session), db4o will insert a new object. db4o does this because it does not automatically match up objects to be stored, with objects previously stored. It assumes you are inserting a second object which happens to have the same field values.

To make sure you’ve updated the pilot, please return to any of the retrieval examples above and run them again.

Deleting objects

Objects are removed from the database using the delete() method.

Java Code:

   // deleteFirstPilotByName

   ObjectSet result=db.get(new Pilot("Michael Schumacher",0));
   Pilot found=(Pilot)result.next();
   db.delete(found);
   System.out.println("Deleted "+found);
   retrieveAllPilots(db);

Jython Code:

   result=db.get(Pilot("Michael Schumacher",0))
   found=result.next()
   db.delete(found)
   print "Deleted ", found
   proto=Pilot(None,0)
   result=db.get(proto)
   listResult(result)

Let’s delete the other one, too.

    result=db.get(Pilot("Rubens Barrichello",0))
    found=result.next()
    db.delete(found)
    print "Deleted "+found
    proto=Pilot(None,0)
    result=db.get(proto)
    listResult(result)

Please check the deletion with the retrieval examples above.

As with updating objects, the object to be deleted has to be ‘known’ to db4o. It is not sufficient to provide a prototype object with the same field values.

Next Installment:

In our next installment, we will provide the full source code for this tutorial. We will also reflect on the differences between the Jython code and the Java code.

Also, the Jython road map has been updated. It looks like Jython 2.5 Final will be out in January. This is great news. Kudos to the Jython team!

Separation of Concerns Using Decorators

I was thinking that I could have some fun with DB4O and Jython. If I create a generic object factory to instantiate the Java classes I want to use with DB4O, it would be possible for me to wrap the Java classes in a Python class. This would allow me to decorate method calls to indicate that a method is transactional – basically, by using a Python adapter on a Java class, I could use decorators to separate any one of a number of concerns.

I was thinking that when the object factory produces an object, it would use the generic reflector to populate a dictionary of methods or properties that can be called – basically, the factory would examine the Java object to identify its attributes. For the wrapper/mapper to work, I may have to impose some conventions – the basic idea could be useful and cool.

Remember, the far off goal is something that looks and works like Active Record, but for DB40 using Jython. The programmer would need to know very little about DB4O, but each object would know how to save, update and delete itself, and there would a simply way to dynamically query the repository.

Basically, I think Jython may provide the means to play with syntax, and to toy with various nifty ideas. I will post my next installment in the Formula One tutorial series soon.

Forgive me for blithering – I just want to use my blog entries to record my thoughts where I can.

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.