Persistiendo Objetos

Al instalar ZODB, hace de python un lenguaje persistente, permitiendo facilidades como la escritura automática de los objetos en el disco y la lectura cuando son requeridos por algún programa en ejecución.

ZODB utiliza el módulo internamente pickle, para persistir objetos. A continuación un ejemplo de como persistir un objeto pickeable:

class Conferencia:
    def __init__(self, nombre, anio):
        self.nombre = nombre
        self.anio = anio
    def titulo(self):
        return self.nombre.capitalize()

Escribimos algo

from  pickle import dump
pyconar = Conferencia ('PyconAr', 2011)
print pyconar.titulo(), pyconar.anio
f = open('data.pck', 'wb')
pycon = dump(pyconar, f)
f.close()

Lo leemos

from pickle import load
f = open('data.pck', 'rb')
pyconar = load(f)
print pyconar.titulo(), pyconar.anio #Pyconar 2011
print pyconar.__class__ **<Conferencia ...>

Y lo modificamos

from pickle import load, dump
f = open('data.pck', 'rb')
pyconar = load(f)
pyconar.anio = 2012
f.close()
out = open('data.pck', 'wb')
dump(pyconar, out)
out.close()

Entonces ahora podriamos preguntarnos: ¿Por qué no usamos ``pickle`` para persistir objetos en lugar de complicarnos?

Porque eso podria llevarnos a perder "the big picture" ya que ZODB tiene muchas mas caracteristicas... Por ejemplo: administra los objetos para facilitar el trabajo del programador, manteniendo los objetos en memoria RAM, escribiendolos en disco cuando se modifican y eliminándolos de la memoria cuando no se hayan utilizado en suficiente tiempo.

Ahora si: ZODB

Un aspecto que deben cubrir los objetos es que deben ser persistentes. Para que un objeto python pueda ser persistido utilizando ZODB debe ser un dato primitivo (int, char, boolean, string, etc) o un objeto que pertenece a una clase que hereda la subclase persistent.Persistent.

Ejemplo:

>>> import ZODB
>>> from ZODB import FileStorage
>>> from ZODB.DB import DB
>>> import transaction
>>> storage = FileStorage('data.fs')
>>> db = DB(storage)
>>> connection = db.open()
>>> root = connection.root()
>>> root['pyconar'] = pyconar
>>> transaction.commit()
>>> db.close()

¿Y Ahora que ventajas tenemos?

Lo primero es que la capa de mapeo a la base de datos desaparece, y pasamos de tener esto:

[ aplicación ]  <------> [ ORM ] <------->  [ BDD Relacional ]

   Objetos                                    Relacional / SQL

a esto:

[ apliación ]  <------>  [ ZODB ]

   Objetos               Objetos

Por otro lado los Benchmarks son muy alentadores, veamos este con PostgreSql

Con estos datos podemos ver que:

• Los caches de gran tamaño son importante para escribir tanto como para leer.
• Necesitamos una solución para mas de 10 millones de objetos.
• ¿Si ZODB maneja 250 inserciones/segundos en el pico máximo de volumen de datos por que toma un minuto manejar 25 documentos?

Conclusiones

ZODB es una base de datos orientada a objetos bastante simple y transparente. No es una buena opción cuando se utilizan modelos de tablas.

Las consultas se hacen por interacción con objetos, no con la base de datos. Puede utilizarse para aplicaciones sensillas o escalables.

Para instalar

$ easy_install ZODB3

o

$ pip install ZODB3

Basado en:

• "ZODB: Apython Persistence System", PyCon 2011, Chris Mc Donough (http://blip.tv/pycon-us-videos-2009-2010-2011/pycon-2011-zodb-a-python-persistence-system-4897373)
• "Tira tu base de datos relacional a la basura", Roberto Allende (http://robertoallende.com/es/tira-tu-base-de-datos-relacional-a-la-basura)
• Proyecto: http://www.zodb.org/