Home > Articles > Programming > Python

ZODB for Python Programmers

  • PrintPrint
  • Share ThisShare This
  • DiscussDiscuss
Close Window

Michel Pelletier 

Learn more…

Zope Book, TheZope Book, The
Jul 17, 2001

Sorry, this author hasn't posted any blogs.

Zope Book, The

From the author of
Zope Book, The

This article covers the basics of the Zope Object Database and its use with the Python programming language.
This article is excerpted from The Zope Book, by Michael Pelletier and Amos Latteier.

Zope Object Database (ZODB) is a powerful object database for Python objects that comes with Zope (http://www.zope.org). If you've ever worked with a relational database, such as PostgreSQL, MySQL, or Oracle, then you should be familiar with the role of a database. If not, just start by thinking of it as short or long-term storage for your application data.

For many tasks, relational databases are clearly a good solution, but sometimes relational databases don't fit well with your object model. If you have lots of different kinds of interconnected objects with complex relationships and changing schemas then ZODB might be worth giving a try.

A major feature of ZODB is transparency. You do not need to write any code to explicitly read or write your objects to or from a database. Just put your persistent objects into a container that works just like a Python dictionary. Everything inside this dictionary is saved in the database. This dictionary is said to be the root of the database. It's like a magic bag; any Python object that you put inside it becomes persistent.

Actually, there are a few restrictions on what you can store in the ZODB. You can store any objects that can be pickled into a standard, cross-platform serial format. Objects such as lists, dictionaries, and numbers can be pickled. Objects such as files, sockets, and Python code objects, cannot be stored in the database because they cannot be pickled. For more information on pickling, see the Python pickle module documentation (http://www.python.org/doc/current/lib/module-pickle.html).

A Simple Example

The first thing you need to do to start working with ZODB is to create a root object. This process involves first opening a connection to a storage, which is the actual back-end that stores your data.

ZODB supports many pluggable storage back-ends, but for the purposes of this article I'm going to show you how to use the FileStorage back-end storage, which stores your object data in a file. Other storages include storing objects in relational databases, Berkeley databases, and a client-to-server storage, which stores objects on a remote storage server.

To set up a ZODB, you must first install it. ZODB comes with Zope, so the easiest way to install ZODB is to install Zope and use the ZODB that comes with your Zope installation. For those of you who don't want all of Zope, but want ZODB, see the instructions for downloading StandaloneZODB from the ZODB (http://www.zope.org/Wikis/ZODB/FrontPage) web page.

StandaloneZODB can be installed into your system's Python libraries using the standard distutils Python module.

After installing ZODB, you can start to experiment with it right from the Python command-line interpreter. For example, try the following Python code in your interpreter:

    >>> from ZODB import FileStorage, DB
>>> storage =
FileStorage.FileStorage('mydatabase.fs')
>>> db = DB(storage)
>>> connection = db.open()
>>> root = connection.root()

Here, you create storage and use the mydatabse.fs file to store the object information. Then, you create a database that uses that storage.

Next, the database needs to be opened by calling the open() method. This returns a connection object to the database. The connection object then gives you access to the root of the database with the root() method.

The root object is the dictionary that holds all of your persistent objects. For example, you can store a simple list of strings in the root object:

   >>> root['employees'] = ['Mary', 'Jo', 'Bob']

Now, you have changed the persistent database by adding a new object, but this change so far is only temporary. To make the change permanent you must commit the current transaction:

   >>> get_transaction().commit()

Transactions group lots of changes into one atomic operation. In a later article, I'll show you how this is a very powerful feature. For now, you can think of committing transactions as checkpoints where you save the changes you've made to your objects so far. Later on, I'll show you how to abort those changes, and how to undo them after they are committed.

Now let's find out if our data was actually saved. First close the database connection:

   >>> connection.close()

Then quit Python. Now start the Python interpreter up again, and connect to the database you just created:

    >>> from ZODB import FileStorage, DB
>>> storage =
FileStorage.FileStorage('mydatabase.fs')
>>> db = DB(storage)
>>> connection = db.open()
>>> root = connection.root()

Now, let's see what's in the root:

>>> root.items() [('employees', ['Mary', 'Jo', 'Bob'])]

There's your list. If you had used a relational database, you would have had to issue a SQL query to save even a simple Python list, such as the preceding example. You would have also needed some code to convert a SQL query back into the list when you wanted to use it again. You don't have to do any of this work when using ZODB. Using ZODB is almost completely transparent; in fact, ZODB-based programs often look suspiciously simple!

Keep in mind that ZODB's persistent dictionary is just the tip of the persistence iceberg. Persistent objects can have attributes that are themselves persistent. In other words, even though you might have only one or two top-level persistent objects as values in the persistent dictionary, you can still have thousands of subobjects lower than them. This is, in fact, how Zope does it. In Zope, only one top-level object exists, which is the root application object for all other objects in Zope.

  • Share ThisShare This
  • Your Account

Discussions

Make a New Comment

You must log in in order to post a comment.

Related Resources

Buck WoodySQL Server 101 Back to Basics at SQL Bits
By Buck Woody on September 7, 2010 No Comments

I’m traveling to the United Kingdom (York, England, to be specific) in September, joining Brent Ozar, Brad McGehee, Kevin Kline, Simon Sabin – and a host of other top-notch speakers. They will be covering deep technical topics ranging from server health checks to SANs and Virtualization. So what will I be talking about? SQL Server 101.

 

Every time I attend a conference like this, I’m amazed at the depth of technical information you can learn about. And for those of us who make a living at SQL Server, they are a great bargain – you get a “knowledge accelerator” that helps you do your job.

Buck WoodyDealing with Data Defining the Components to Tune
By Buck Woody on September 2, 2010 No Comments

I've been reading a fascinating article about the Large Hadron Collider, or LHC facility. It's a scientific research facility that houses a particle collider, which generates an incredible amount of data. Their original plan was to stream the data to tape, then sending the data to "islands" closer to the users, offloading the network as quickly as possible. But they found that the network could handle the streaming better than they thought - so they now stream the data directly to the users, saturating the network. It's a new way of thinking about moving the data around.

Buck WoodyWork Swarms
By Buck Woody on August 24, 2010 No Comments

I’ve been reading some excerpts from Gartner, Inc. and information from others on the changes they are seeing in the workplace. It’s holding true where I work and in the workplaces of the other data professionals I work with. One of those new trends is called “Swarming” – where informal teams get together to work on a particular project, and in some cases a single task, as a group. They then move on to another task, and so on, like a swarm of bees. These are less formal than the “Tiger Teams” I used to be part of that were also temporary, but had a more formal banding and dis-banding. The Gartner article states that this is more often the norm in companies than not.

See All Related Blogs

Informit Network