The Zope Object Database (ZODB) is an
object-oriented database
An object database or object-oriented database is a database management system in which information is represented in the form of objects as used in object-oriented programming. Object databases are different from relational databases which are ...
for transparently and persistently storing
Python
Python may refer to:
Snakes
* Pythonidae, a family of nonvenomous snakes found in Africa, Asia, and Australia
** ''Python'' (genus), a genus of Pythonidae found in Africa and Asia
* Python (mythology), a mythical serpent
Computing
* Python (pro ...
objects. It is included as part of the
Zope
Zope is a family of free and open-source web application servers written in Python, and their associated online community. Zope stands for "Z Object Publishing Environment", and was the first system using the now common object publishing methodolo ...
web
application server
An application server is a server that hosts applications or software that delivers a business application through a communication protocol.
An application server framework is a service layer model. It includes software components available to a ...
, but can also be used independently of Zope.
Features of the ZODB include: transactions, history/undo, transparently pluggable storage, built-in caching,
multiversion concurrency control
Multiversion concurrency control (MCC or MVCC), is a concurrency control method commonly used by database management systems to provide concurrent access to the database and in programming languages to implement transactional memory.
Description
W ...
(MVCC), and scalability across a network (using ).
History
* Created by Jim Fulton of Zope Corporation in the late 90s.
* Started as simple Persistent Object System (POS) during Principia development (which later became Zope)
* ZODB 3 was renamed when a significant architecture change was landed.
* ZODB 4 was a short lived project to re-implement the entire ZODB 3 package using 100% Python.
Implementation
Basics
ZODB stores Python objects using an extended version of Python's built-in object persistence (pickle). A ZODB database has a single root object (normally a dictionary), which is the only object directly made accessible by the database. All other objects stored in the database are reached through the root object. Objects referenced by an object stored in the database are automatically stored in the database as well.
ZODB supports concurrent transactions using
MVCC and tracks changes to objects on a per-object basis. Only changed objects are committed. Transactions are non-destructive by default and can be reverted.
Example
For example, say we have a car described using 3 classes
Car
,
Wheel
and
Screw
. In Python, this could be represented the following way:
class Car: ..class Wheel: ..class Screw: ..
myCar = Car()
myCar.wheel1 = Wheel()
myCar.wheel2 = Wheel()
for wheel in (myCar.wheel1, myCar.wheel2):
wheel.screws = crew(), Screw()
If the variable mycar is the root of persistence, then:
zodb mycar'= myCar
This puts all of the object instances (car, wheel, screws etc.) into storage, which can be retrieved later. If another program gets a connection to the database through the mycar object, performing:
car = zodb myCar'
And retrieves all the objects, the pointer to the car being held in the
car
variable. Then at some later stage, this object can be altered with a Python code like:
car.wheel3 = Wheel()
car.wheel3.screws = crew()
The storage is altered to reflect the change of data (after a commit is ordered).
There is no declaration of the data structure in either Python or ZODB, so new fields can be freely added to any existing object.
Storage unit
For persistence to take place, the Python Car class must be derived from the persistence. Persistent class — this class both holds the data necessary for the persistence machinery to work, such as the internal object id, state of the object, and so on, but also defines the boundary of the persistence in the following sense: every object whose class derives from Persistent is the atomic unit of storage (the whole object is copied to the storage when a field is modified).
In the example above, if
Car
is the only class deriving from Persistent, when
wheel3
is added to car, all of the objects must be written to the storage. In contrast, if
Wheel
also derives from Persistent, then when
carzz.wheel3 = Wheel
is performed, a new record is written to the storage to hold the new value of the
Car
, but the existing
Wheel
are kept, and the new record for the
Car
points to the already existing
Wheel
record inside the storage.
The ZODB machinery doesn't chase modification down through the graph of pointers. In the example above,
carzz.wheel3 = something
is a modification automatically tracked down by the ZODB machinery, because
carzz
is of (Persistent) class
Car
. The ZODB machinery does this by marking the record as
dirty
. However, if there is a list, any change inside the list isn't noticed by the ZODB machinery, and the programmer must help by manually adding
carzz._p_changed = 1
, notifying ZODB that the record actually changed. Thus, to a certain extent the programmer must be aware of the working of the persistence machinery.
Atomicity
The storage unit (that is, an object whose class derives from Persistent) is also the
atomicity unit. In the example above, if
Cars
is the only Persistent class, a thread modifies a Wheel (the
Car
record must be notified), and another thread modifies another
Wheel
inside another transaction, the second commit will fail. If
Wheel
is also Persistent, both
Wheels
can be modified independently by two different threads in two different transactions.
Class persistence
The class persistence—writing the class of a particular object into the storage—is obtained by writing a kind of "fully qualified" name of the class into each record on the disk. In Python, the name of the class involves the hierarchy of directory the source file of the class resides in. A consequence is that the ''source'' file of persisting object cannot be moved. If it is, the ZODB machinery is unable to locate the class of an object when retrieving it from the storage, resulting into a broken object.
ZEO
Zope Enterprise Objects (ZEO) is a ZODB storage implementation that allows multiple client processes to persist objects to a single ZEO server. This allows transparent scaling.
Pluggable storages
* Network Storage (aka ZEO) - Enables multiple python processes load and store persistent instances concurrently.
* File Storage - Enables a single python process to talk to a file on disk.
* relstorage - Enables the persistence backing store to be a
RDBMS
A relational database is a (most commonly digital) database based on the relational model of data, as proposed by E. F. Codd in 1970. A system used to maintain relational databases is a relational database management system (RDBMS). Many relation ...
.
* Directory Storage - Each persistent data is stored as a separate file on the filesystem. Similar to FSFS in
Subversion
Subversion () refers to a process by which the values and principles of a system in place are contradicted or reversed in an attempt to transform the established social order and its structures of power, authority, hierarchy, and social norms. Sub ...
.
* Demo Storage - An in-memory back end for the persistent store.
* BDBStorage - Which uses
Berkeley DB
Berkeley DB (BDB) is an unmaintained embedded database software library for key/value data, historically significant in open source software. Berkeley DB is written in C with API bindings for many other programming languages. BDB stores arbitr ...
back end. Now abandoned.
Failover
Failover is switching to a redundant or standby computer server, system, hardware component or network upon the failure or abnormal termination of the previously active application, server, system, hardware component, or network in a computer net ...
technologies
* Zope Replication Services (ZRS) - A commercial add-on (open-source since May 2013) that removes the single point of failure, providing hot backup for writes and load-balancing for reads.
* zeoraid - An open source solution that provides a proxy Network Server that distributes object stores and recovery across a series of Network Servers.
* relstorage - since RDBMS technologies are used this obviates need for ZEO server.
* NEO - Distributed (fault tolerance, load-balancing) storage implementation.
References
{{Reflist
External links
ZODB Official SiteZODB BookZODB programming guideIntroduction to the Zope Object Database
Cross-platform software
Free database management systems
Object-oriented database management systems
ORDBMS software for Linux
Python (programming language) software