[Python-es] Re: [Python-es] Re: [Python-es]Re: [Python-es] Re: [Python-es]¿Como quereis laInterfaz (API) de lacapa de persistencia?

[Ernesto Revilla]

----- Original Message -----
From: "Antoni Aloy López" <aloy en ctv.es>
> Tal como se plantean las clases de persistencia parece que siempre es
> condición indispensable disponer de una capa intermedia, de un middleware,
la
> cual normalmente también implica un servidor de aplicaciones.
Eso no es cierto, aunque sea un uso habitual. Una aplicación simple de
libreta de direcciones podría tener la capa de persistencia y por ejemplo
MetaKit (http://www.equi4.com ) como base de datos. Igualmente, podría
crearse una interfaz XML-RPC y dejar correr la capa con algún back-end de
almacenamiento, tipo postgresql o ZODB correr como proceso servidor, lo que
no llamaría 'servidor de aplicaciones' (sino más bien 'servidor de objetos).

> La complejidad que conlleva un servidor de aplicaciones tanto a nivel de
> programación, mantenimiento por parte del cliente, y su lentitud
intrínseca
> hoy por hoy no lo hacen muy aconsejable para aplicaciones de gestión de
las
> de "toda la vida": contabilidad, gestión comercial, etc.
No estoy para nada de acuerdo contigo. Existen servidores de aplicaciones
como BEA WebLogic, Lotus Domino, IBM Websphere o JBOSS que corren
aplicaciones de gestión. Si te refieres a servidores Python, no se puede
decir que Zope sea lento, aunque hay ciertas dificultades desde el punto de
vista de creación de aplicaciones, por el fuerte marco al que se tienen que
integrar (en concreto hay que configurar toda la seguridad para un producto,
y tener en cuenta determinadas clases bases). Por otra parte, Guido y otros
están destrás de Python, pero ninguna empresa grande, como SUN, que a demás
de especificar Java, ha creado otras especificaciones orientadas al mundo
empresarial, como JDBC, JTA/JTS, JDO, EJB, JNDI y muchos más. Si hubiese
habido sólo la cuarta parte de publicidad para Python que para Java, ya
habríamos llegado bastante más lejos.

> Yo por ahora me conformaría con algo intermedio entre la capa de
persistencia
> "académica" y la capa de persistencia "práctica". Aquí el trabajo de Opal
se
> puede aprovechar bastante, ya que nos permitiría definir un objeto que
> haciendo uso de db_row mapease un registro de la base de datos.
Yo también hice una encapsulación para filas de tablas. Un concepto
realmente interesante, pero ahora trabajaremos con alrededor de 100
tablas/clases para entre 20 y 40 clientes, y necesitamos algo más abstracto.
Además, la capa no es tan académica como puedes ver en los white papers de
Scott Ambler (www.ambysoft.com/persistenceLayer.html). Un gran + es crear la
independencia respecto a los vendedores de RDBMS. Puede costar un ojo migrar
por ejemplo entre Oracle a MSSQL.

Cierto es que mi capa será lenta. Tiene que realizar chequeo de tipos,
reglas de validación, registrar llamadas de métodos, comprobar la seguridad
y actualizar otros valores sobre el objeto en cuestión. Realmente me da un
poco miedo que no se pueda usar: Pero hay caché, las operaciones se realizan
en RAM y el hardware en general no es demasiado caro. Ya os contaré.

> Queda por resolver por ahora el tema de detectar que se ha cambiado un
valor
> del objeto ya que la generación de código SQL no es complicada.
Yo consigo esto, porque dentro de las transacciones de usuario sólo existen
objetos proxies que apuntan a otros objetos en la caché. Cualquier set crea
una entrada en el diccionario __dict__ local, con lo que sólo se guardan las
modificaciones. Y si un atributo no se encuentra en el objeto proxy , se
busca en el objeto al que apunta.

Python usa exáctamente el mismo mecanismo para instancias y clases.

Erny