Programming Python (178 page)

In this chapter,
we’ve seen OODBs that store native Python objects
persistently, as well as SQL databases that store information in tables.
It turns out that there is another class of system that attempts to bridge
the object and table worlds, which I’ve hinted at earlier in this chapter:
ORMs graft the Python class model onto the tables of relational databases.
They combine the power of relational database systems with the simplicity
of Python class-based syntax—you don’t need to forgo SQL-based
databases
, but you can still store data that
seems like Python objects to your scripts.

Today, there are two leading open source third-party systems that
implement this mapping: SQLObject and SQLAlchemy. Both are fairly complex
systems that we cannot do full justice to in this text, and you’re best
off researching their documentation on the Web for the full story (there
are also dedicated books covering SQLAlchemy today). Moreover, neither is
completely Python 3.X ready as I write these words, so we can’t run live
examples with them in this text.

To give you a slightly more concrete flavor of the ORM model,
though, here is a very quick look at how you might use it to create and
process database records in the
SQLObject
system. In brief, SQLObject maps:

For example, to create a table, we define it with a class, with
class attributes that define columns, and call its creation method (this
code is derived from a more complete example at SQLObject’s
website):

from sqlobject import *
sqlhub.processConnection = connectionForURI('sqlite:/:memory:')
class Person(SQLObject):                  # class: describes table
first = StringCol()                   # class attributes: row columns
mid   = StringCol(length=1, default=None)
last  = StringCol()
Person.createTable()                      # create a database table

Once created, making an instance automatically inserts a row into
the database, and attribute fetches and assignments are automatically
mapped to fetches and updates of the corresponding table row’s
column:

p = Person(first='Bob', last='Smith')     # new instance: makes and inserts row
p                                         # prints all attributes by name
p.first                                   # attribute: fetches row column
p.mid = 'M'                               # attribute: updates record

Existing rows/instances may be fetched by methods calls, and we can
assign multiple columns/attributes with a single update operation:

p2 = Person.get(1)                        # fetch existing record/instance: p2 is p
p.set(first='Tom', last='Jones')          # update two attributes/fields at once

In addition, we can select by column values by creating a query
object and executing it:

ts = Person.select(Person.q.first=='Tom') # query: select by column value
list(ts)                                  # run the query: list of instances
tjs = Person.selectBy(first='Tom', last='Jones')   # alternative query form (AND)

Naturally, this barely scratches the surface of the available
functionality. Even at this level of complexity, though, this is quite a
trick—SQLObject automatically issues all the SQL required to fetch, store,
and query the table and rows implied by the Python class syntax here.
Again, the net effect allows systems to leverage the power of
enterprise
-
level
relational databases, but still use
familiar Python class syntax to process stored data in Python
scripts.

The code used with the SQLAlchemy ORM is of course very different,
but the end result is functionally similar. For more details on ORMs for
Python, consult your friendly neighborhood web search engine. You can also
learn more about such systems by their roles in some larger web
development frameworks; Django, for instance, has an ORM which is another
variation on this
theme.

Instead of going into
additional database interface details that are freely
available on the Web, I’m going to close out this chapter by directing you
to a supplemental example that shows one way to combine the GUI technology
we met earlier in the text with the persistence techniques introduced in
this chapter. This example is named PyForm—a Python/tkinter GUI designed
to let you browse and edit tables of records:

Although this example is about GUIs and persistence, it also
illustrates Python design techniques. To keep its implementation both
simple and type-independent, the PyForm GUI is coded to expect tables to
look like dictionaries of dictionaries. To support a variety of table and
record types, PyForm relies on separate wrapper classes to translate
tables and records to the expected protocol:

The net effect is that PyForm can be used to browse and edit a wide
variety of table types, despite its dictionary interface expectations.
When PyForm browses shelves and DBM files, table changes made within the
GUI are persistent—they are saved in the underlying files. When used to
browse a shelve of class instances, PyForm essentially becomes a GUI
frontend to a simple object database that is built using standard Python
persistence tools. To view and update a shelve of objects with PyForm, for
example, code like the following will suffice:

import shelve
from formgui import FormGui                 # after initcast
db = shelve.open('../data/castfile')        # reopen shelve file
FormGui(db).mainloop()                      # browse existing shelve-of-dicts

To view or update a shelve of instances of an imported
Actor
class, we can use code like this:

from PP4E.Dbase.testdata inport Actor
from formgui import FormGui                 # run in TableBrowser dir
from formtable import ShelveOfInstance
testfile = '../data/shelve'                 # external filename
table = ShelveOfInstance(testfile, Actor)   # wrap shelf in Table object
FormGui(table).mainloop()
table.close()                               # close needed for some dbm

Figure 17-1
captures
the scene under Python 3.1 and Windows 7 when viewing a shelve of
persistent class instance objects. This PyForm session was kicked off by a
command-line described in its form table module’s self-test code:
formtable.py shelve 1
, and omit the
1
(or pass it as
0
) to avoid reinitializing the shelve at the
start of each session so changes are retained.

PyForm’s GUI can also be started from the PyDemos launcher we met in
Chapter 10
, though it does not save changes
persistently in this mode. Run the example on your own computer to get a
better sample of its operation. Though not a fully general Python
persistent object table viewer, PyForm serves as a simple object database
front end.

Figure 17-1. PyForm displaying a shelve of Actor objects

Because we are short on time and space in this edition, I’m going to
omit both the source code for this example and its description here. To
study PyForm, see the following directory in the book’s examples package
distribution described in the
Preface
:

C:\...\PP4E\Dbase\TableBrowser

See especially the
Documentation
subdirectory there, which
contains the original
PyForm
overview material from the third edition in a PDF file. PyForm’s source
code files are ported to Python 3.X form, though code in the overview
document still shows its 2.X third edition roots. For the purposes of the
published portions of this book, let’s move on to the next chapter and our
next tools topic: data structure
implementations.