ORuM

15 views
Skip to first unread message

Fabio Maulo

unread,
Mar 20, 2009, 9:57:16 PM3/20/09
to altnet-a...@googlegroups.com
Quien me conoce un poco, o me ha leido en algún lado, conoce ya la acronimo ORuM.
La realida es que nunca tuve la ocasión de una buena confrontación sobre el tema.

Para titular la mesa sería:
Object Relational unMapping
Mas allá del ORM.

Quisiera compartir, confrontar, ampliar algunas ideas y verificar la factibilidad.

--
Fabio Maulo

Diego Ramirez

unread,
Mar 21, 2009, 12:55:29 AM3/21/09
to altnet-a...@googlegroups.com
Estuve viendo el ejemplo de Ayende, parece la panacea. Adios a los
hbm??. Existe algún ejemplo concreto??.
Saludos
--
Ramirez, Diego Alcides
Ingeniero en Sistemas de Información
Tel:(+543731)-15405075
Blog: www.thedarsideofit.com.ar
Equipo de Desarrollo - VGM Sistemas
www.vgmsistemas.com.ar

Fabio Maulo

unread,
Mar 21, 2009, 8:56:31 AM3/21/09
to altnet-a...@googlegroups.com
El 21 de marzo de 2009 1:55, Diego Ramirez <alcides...@gmail.com> escribió:

Estuve viendo el ejemplo de Ayende, parece la panacea. Adios a los
hbm??. Existe algún ejemplo concreto??.
Saludos

Cual es el ejemplo de Oren ?

Este es un poco antiguo
Si te fijas en el codigo de ese post
cfg = new Configuration();
cfg.Configure();
cfg.Register(typeof(Animal));

con cfg.Register(typeof(Animal)) y "sin mapping" podes empezar a trabajar.

De todas formas yo quisiera hablar de los conceptos/teorias que hay detrás de algo que se puede hacer.
ORuM es una visión no un framework.

El tema es que la visión tiene possibilidad de ser implementada.

--
Fabio Maulo

Dario Quintana

unread,
Mar 21, 2009, 10:18:14 AM3/21/09
to altnet-a...@googlegroups.com
Hola gente

La verdad que esto se necesitaría inclusive dentro de NHibernate, por ahora se lo vé dentro de frameworks que están arriba de NH ó Hib (Hibernate.Annotations, Fluent NHibernate). Por ejemplo dentro de NHibernate ahora para definir un bag se hace más que esto:
<bag name="ProductosVendidos"/>
Pero creo que con esta información a veces es necesario.

Yo había comenzado el port de NH.Annotations en un SVN local, e incluía algunos conceptos básicos: mapeo automático de properties/fields (dependiendo cuál es el default) y si se detectaba una collection debía ser un Bag[One-To-Many]. Era un comienzo, y para ejercitar un poco.

La idea es que los defaults sean configurados, si bien el framework vendria con defaults, por ejemplo, mapeo a fields directamente, yo podría cambiar el defaults diciendo: prefiero el mapeo por backfield (cuando se usa auto-properties).

Esto es interesante para charlarlo, lo bueno sería es ver cuales son los defaults más usados para facilitar un poco la vida.

Qué piensan?

2009/3/21 Fabio Maulo <fabio...@gmail.com>



--
Dario Quintana
http://darioquintana.com.ar

Fabio Maulo

unread,
Mar 21, 2009, 10:31:06 AM3/21/09
to altnet-a...@googlegroups.com
El 21 de marzo de 2009 11:18, Dario Quintana <cont...@darioquintana.com.ar> escribió:
Qué piensan?

Te acordas allá por el 2006 cuando hablabamos de NH como OODB ?
Bueno ORuM viene de allí ;)
Ni anotaciones ni mapping.

Yo quisiera llegar a : "che, yo tengo este dominio que tendría que persistir en ORACLE, fijate vos! a mi lo que me interesa es que persista."

El DSL sería:
Che.Tengo("MiDominio.dll").Que.TieneQuePersistirEn("ORACLE").FijateVos();

--
Fabio Maulo

Miguel Saez

unread,
Mar 21, 2009, 10:41:42 AM3/21/09
to altnet-a...@googlegroups.com
Lo que plantean es similar al modelo que sigue el ActiveRecord de Ruby on Rails, solo que la acción de crear las tablas y sus relaciones a partir del modelo de objetos se hace por medio de un script.
 
De hecho hay algunas críticas a Entity Framework, ya que es posible generar el modelo de entidades a partir de la definición de la base de datos y no a la inversa. El punto de partir de un modelo de objetos se vuelve más necesario para quienes practican TDD y modifican constantemente el modelo.
 
Opiniones?

2009/3/21 Fabio Maulo <fabio...@gmail.com>

Dario Quintana

unread,
Mar 21, 2009, 10:41:42 AM3/21/09
to altnet-a...@googlegroups.com
Si, me acuerdo :-) y también quiero lo mismo. Varias veces lo repensé al tema.

Solo que a veces pienso, como estamos trabajando siempre con una base relacional: Qué estrategia de Herencia elegir por default? Bueno, elegimos una, pero qué pasa si a una parte de nuestro modelo queremos cambiarla por que no convienen las consultas (muy kilometricas), bueno, en ese caso habria que agregar una "corrección", que se podría configurar (ya sea con Annotations, Fluent, o Configuración común y corriente). Pero la idea es que el default apunte a la "gran mayoría".

A veces ni las bases OO escapan a una "corrección" sobre lo que se mapea. Db4o te permite usar [NonSerialized] o elegir tu propio attribute (lo cual lo hace menos intrusivo) sobre aquellos fields (si, por que este tipos de bases persisten el estado del objeto: los fields) que deseo que no sean persistentes.

2009/3/21 Fabio Maulo <fabio...@gmail.com>

Dario Quintana

unread,
Mar 21, 2009, 11:02:20 AM3/21/09
to altnet-a...@googlegroups.com
Sin ir más lejos, un framework más cercano que lo hace es Hibernate.Annotations (java).

Por otro lado, con EF, más allá de que pueda o no generar DDL (lo cual es muy bueno si lo hiciese), queda fuera de la ecuación, tiene un grado de intrusión muy alto como para poder pensarlo como hacer "mapping automático" o ORuM (como lo plantea Fabio).

Más alla de esas desventajas, EF tiene otras que no vienen al caso en este momento, creo que las habia expresado en las listas de c# del MUG el año pasado.

2009/3/21 Miguel Saez <miguel.a...@gmail.com>

Lo que plantean es similar al modelo que sigue el ActiveRecord de Ruby on Rails, solo que la acción de crear las tablas y sus relaciones a partir del modelo de objetos se hace por medio de un script.
 
De hecho hay algunas críticas a Entity Framework, ya que es posible generar el modelo de entidades a partir de la definición de la base de datos y no a la inversa. El punto de partir de un modelo de objetos se vuelve más necesario para quienes practican TDD y modifican constantemente el modelo.
 
Opiniones?

Claudio Meschini

unread,
Mar 21, 2009, 11:36:05 AM3/21/09
to altnet-a...@googlegroups.com
Como andan?

Antes que nada, felicitaciones a los que tomaron la iniciativa de alt.net-argentina/hispano. Ojala esto crezca rapidamente.

En cuanto al tema de ORuM deje publicado a principios de enero un framework denominado "Quetzal" bajo licencia GPL 3.0 que a partir de las clases del dominio (aasembly) genera los mapping de NH de forma automatica, al estilo de lo que hace Fluent NH con su autoconfiguración. Este es el link al svn:http://svn2.assembla.com/svn/Quetzal

Como señala Darío este tambien un framework que, al igual que Fluent, esta por encima de NH ya que usa su propio engine de analisis de las clases del dominio no solo para generar los mappings sino por ejemplo tambien vistas (MVC).

El engine del framework reconoce properties/fields, ids, y relaciones entre las clases/propiedades del "modelo", mapeandolo adecuadamente. (many-to-many,one-to-many, etc) y propone tambien ciertas configuraciones por default haciendo uso de "convention over configuration".

Uno de los principales problemas que se me planteo, como señala tambien Darío, era como poder hacer la configuración "fina" del modelo (por ej.: estrategia de mapeo para la herencia de clases) ya que era bastante complicado extenderlo. En ese sentido generar el .hbm era la opcion más simple porque de última podía tocarlo a mano y no volver a generarlo. Sin embargo en la actualidad el "engine" del framework permite extenderlo de una forma muy sencilla. Lo otro que me impedía hacer algo totalmente "on the fly" eran mis nulos conocimientos sobre la arquitectura interna de NH.

Me parece que con un poco mas de esfuerzo estamos cerca de lo que plantea Fabio

Espero sus opiniones

Claudio
claudiomeschini.blogspot.com


Rodolfo Finochietti

unread,
Mar 21, 2009, 11:35:30 AM3/21/09
to altnet-a...@googlegroups.com
Pienso que con C#4 implementar una libreria/fwk sencillo de mapping automático simil ActiveRecord en Rails va a ser sencillo (gracias IDynamicObject!). Estuve haciendo una pruebas y tengo un proto andando. Lo que no es posible evaluar con el CTP que hay disponible es la velocidad.
 
PD: Lo que se vio de EFX 2 en el summit promete...
 

From: altnet-a...@googlegroups.com [altnet-a...@googlegroups.com] On Behalf Of Dario Quintana [cont...@darioquintana.com.ar]
Sent: Saturday, March 21, 2009 12:02
To: altnet-a...@googlegroups.com
Subject: Re: ORuM

Angel "Java" Lopez

unread,
Mar 21, 2009, 11:42:56 AM3/21/09
to altnet-a...@googlegroups.com
Disculpen la intervencion corta: eso de "che, yo tengo este X tendria que usar Y, fijate vos!", es el leit-motiv del AjGenesis.... ;-)
 
Cambien X por dominio, servicios, arbol de menu, modelo en general, Y por Oracle, SQL-Server, ASP.NET MVC, PHP, IronPindongaWeb3.0#....
 
El "che" es una expresion italiana? ;-)

Dario Quintana

unread,
Mar 21, 2009, 11:47:20 AM3/21/09
to altnet-a...@googlegroups.com
Se podrían tomar varios conceptos del framework.

Un problema que le veo es la generación de codigo (acá se me vienen varios encima), pero la idea es evitar, en este caso, la generación de Xml e interactuar con el core del Framework sin intermediarios. Uno de los motivos, cuando se tienen más de 100 entidades, el startup se pone violento.

2009/3/21 Claudio Meschini <cmes...@gmail.com>

Claudio Meschini

unread,
Mar 21, 2009, 11:54:55 AM3/21/09
to altnet-a...@googlegroups.com
Si, aunque mi experiencia trabajando con 50 clases es que la generacion es "inmediata", comparto que la idea de poder trabajar directamente con el core de NH es mejor. El único problema que  habría que resolver es como detectar y propagar el cambio del modelo (por ej. Se agrega una propiedad o una coleccion a una clase) y que eso impacte en la estructura de la base de datos. Esto quizas se podría resolver versionando y comparando los script que genera NH. Es una idea.

Claudio
claudiomeschini.blogspot.com

Dario Quintana

unread,
Mar 21, 2009, 12:10:38 PM3/21/09
to altnet-a...@googlegroups.com
Los cambios en el modelo se solucionan con SchemaUpdate, que ya soporta varios RDBMS.

2009/3/21 Claudio Meschini <cmes...@gmail.com>

Dario Quintana

unread,
Mar 21, 2009, 12:17:39 PM3/21/09
to altnet-a...@googlegroups.com
El cambio es menos traumático con SchemaUpdate que al hacer Refactoring en bases como Db4o, acá se complica un poco más.

Queda descartado el entorno de Testeo, aquí donde se cambia algo, se refleja automáticamente en un CREATE o en recrear la base db4o (borrar y crear nuevamente el archivo).

2009/3/21 Dario Quintana <cont...@darioquintana.com.ar>

Los cambios en el modelo se solucionan con SchemaUpdate, que ya soporta varios RDBMS.

Claudio Meschini

unread,
Mar 21, 2009, 12:44:49 PM3/21/09
to altnet-a...@googlegroups.com
El punto que planteaba, es que la discusion sobre si conviene "generar" o no los mappings, en cuanto al tiempo que esto llevaría si se generan cada vez que se inicia la aplicación, (es este el escenario en que estas pensando?) se justificaria si tuvieramos automatizado tambien la propagación de los cambios a la BD. Porque sino salvo excepciones hay que parar la aplicación, para impactar los cambios de la BD, estoy hablando en el entorno de produccion, y aplicar manualmente los cambios con la consabida perdida de tiempo, en un entorno de testeo no me parece una discusión relevante.

Salvo que te entienda mal y que a lo que te estes refiriendo es que "configurar" directamente "on the fly" NH sea más rápido que levantar los .hbm para configurar la session.

Claudio
claudiomeschini.blogspot.com

Dario Quintana

unread,
Mar 21, 2009, 1:11:56 PM3/21/09
to altnet-a...@googlegroups.com
Si se cambia el modelo, en un entorno de producción va a ver cambios, o se soluciona con SchemaUpdate o hay que parar todo, no hay muchas opciones.

2009/3/21 Claudio Meschini <cmes...@gmail.com>

El punto que planteaba, es que la discusion sobre si conviene "generar" o no los mappings, en cuanto al tiempo que esto llevaría si se generan cada vez que se inicia la aplicación, (es este el escenario en que estas pensando?) se justificaria si tuvieramos automatizado tambien la propagación de los cambios a la BD. Porque sino salvo excepciones hay que parar la aplicación, para impactar los cambios de la BD, estoy hablando en el entorno de produccion, y aplicar manualmente los cambios con la consabida perdida de tiempo, en un entorno de testeo no me parece una discusión relevante.

Salvo que te entienda mal y que a lo que te estes refiriendo es que "configurar" directamente "on the fly" NH sea más rápido que levantar los .hbm para configurar la session.

Claudio
claudiomeschini.blogspot.com

Fabio Maulo

unread,
Mar 21, 2009, 1:14:16 PM3/21/09
to altnet-a...@googlegroups.com
Es largo explicarlo por mail por eso quiero sentarme con algunas mentes brillante y charlarlo.

Por un momento olvidense de NH, EF etc. tambien olvidensen de tener un DSL en el cual tengo si o si que definir representaciones que tenga a que ver con persistencia
Hago un ejemplo simple...
Tomen un eschema de herencia.
Usando tecnicas de ORM una herencia se puede persistir usando :
table-per-class
table-per-class-hierarchy
table-per-concrete-class
En algunos framework tambien se pueden usar tecnicas mixstas.

Cual es el proceso mental que lleva a eleguir una representación en lugar que otra ?
Si las decisiones que se toman son definidas, que es lo que me impide a que sea una implementación C# la que toma esas decisiones ?
--
Fabio Maulo

Fabio Maulo

unread,
Mar 21, 2009, 1:17:24 PM3/21/09
to altnet-a...@googlegroups.com
Esto tambien es discutible...
Un modelo que terminó en producción tiene su representación frizada.
A partir de una representación persistente frizada las decisiones sobre lo que se agregó/modificó pueden cambiar...
En fin...
El proceso mental que siempre hacemo para tomar esas decisiones se puede expresar en C# ?

--
Fabio Maulo

Fabio Maulo

unread,
Mar 21, 2009, 1:24:14 PM3/21/09
to altnet-a...@googlegroups.com
Solo para avisar...
En el curso del dia tomo mate... alchol solo a la noche.
--
Fabio Maulo

Fabio Maulo

unread,
Mar 21, 2009, 1:40:44 PM3/21/09
to altnet-a...@googlegroups.com
El 21 de marzo de 2009 12:35, Rodolfo Finochietti <rodo...@lagash.com> escribió:
Pienso que con C#4 implementar una libreria/fwk sencillo de mapping automático simil ActiveRecord en Rails va a ser sencillo (gracias IDynamicObject!). Estuve haciendo una pruebas y tengo un proto andando. Lo que no es posible evaluar con el CTP que hay disponible es la velocidad.

Integrados en C# es interesante. Afuera de C# LinFu ya tiene DynamicObject y tambien NH trabaja con DynamicEntities

Ejemplo:
 
 
PD: Lo que se vio de EFX 2 en el summit promete...
 

From: altnet-a...@googlegroups.com [altnet-a...@googlegroups.com] On Behalf Of Dario Quintana [cont...@darioquintana.com.ar]
Sent: Saturday, March 21, 2009 12:02
To: altnet-a...@googlegroups.com
Subject: Re: ORuM

Sin ir más lejos, un framework más cercano que lo hace es Hibernate.Annotations (java).

Por otro lado, con EF, más allá de que pueda o no generar DDL (lo cual es muy bueno si lo hiciese), queda fuera de la ecuación, tiene un grado de intrusión muy alto como para poder pensarlo como hacer "mapping automático" o ORuM (como lo plantea Fabio).

Más alla de esas desventajas, EF tiene otras que no vienen al caso en este momento, creo que las habia expresado en las listas de c# del MUG el año pasado.

2009/3/21 Miguel Saez <miguel.a...@gmail.com>
Lo que plantean es similar al modelo que sigue el ActiveRecord de Ruby on Rails, solo que la acción de crear las tablas y sus relaciones a partir del modelo de objetos se hace por medio de un script.
 
De hecho hay algunas críticas a Entity Framework, ya que es posible generar el modelo de entidades a partir de la definición de la base de datos y no a la inversa. El punto de partir de un modelo de objetos se vuelve más necesario para quienes practican TDD y modifican constantemente el modelo.
 
Opiniones?

--
Dario Quintana
http://darioquintana.com.ar







--
Fabio Maulo

Claudio Meschini

unread,
Mar 21, 2009, 2:05:40 PM3/21/09
to altnet-a...@googlegroups.com
Yo pienso que estas decisiones son formalizables, siempre y cuando tengamos toda la información que usamos para la toma de decisiones a mano "dentro" de la aplicación, de forma explicita(configuration) o implicita/deducible (convention).

Pongo un ejemplo facil:
Si agrego un field en una clase persistible debería agregar una columna a la tabla correspondiente. Podría deducirlo del DDL generado anteriormente al que le aplico un diff con el actual (que contiene el nuevo campo) y corro el script resultante.

Ahora que pasa si lo que hago es renombrar una propiedad? Tengo que marcarla de alguna manera para que renombre la columna porque el sistema no lo va a poder deducir.

NOTA: Obviamente la utilidad de pensar esto lo digo para un entorno de produccion, porque en testing siempre podemos regenerar toda la base y no importa perder datos.

Claudio
claudiomeschini.blogspot.com




El 21 de marzo de 2009 14:17, Fabio Maulo <fabio...@gmail.com> escribió:

Fabio Maulo

unread,
Mar 21, 2009, 2:31:42 PM3/21/09
to altnet-a...@googlegroups.com
Para mi el tema de prod es algo de enfrentar en otro momento.
Ante quisiera definir los procesos que llevan a representar un domino-de-clases en un schema-de-tablas
Despues me puedo ocupar de representar un domino-de-clases considerando los cambios a partir de otro domino-de-clases.

Paso a Paso (Mostaza Merlo)
--
Fabio Maulo

Dario Quintana

unread,
Mar 21, 2009, 3:48:26 PM3/21/09
to altnet-a...@googlegroups.com
No hay impedimentos de que sean las app C# las que tomen las decisiones. Lo que hay que armar es una lista de ventajas y desventajas de cada una y en qué caso aplicarlas. Lanzo un ejemplo: si se detectan excesiva cantidad de diferencias (> 10, por tirar un número) entre una super-class y una sub-class, descartar el elegir: table-per-class-hierarchy y ver qué otra se podria aplicar, basandose en otros conceptos, pero lo bueno...se descartó un modelo.

Otro factor, que este sí es más dificil de involucrarlo en la decisión, es la manera en que se realizan las queries, si la aplicación está destinada a hacer muchas queries contra la super-clase, y tiene elegido como table-per-class, la cantidad de joins va a ser grande.

Se que es más facil charlarlo, no me considero una mente brillante, pero me gustaría estar en los debates, y dada la distancia, creo que por mail será la manera. A menos que acorden una fecha con anticipación y bueno, veo si puedo viajar, pero es la más dificil.

2009/3/21 Fabio Maulo <fabio...@gmail.com>

Es largo explicarlo por mail por eso quiero sentarme con algunas mentes brillante y charlarlo.

Por un momento olvidense de NH, EF etc. tambien olvidensen de tener un DSL en el cual tengo si o si que definir representaciones que tenga a que ver con persistencia
Hago un ejemplo simple...
Tomen un eschema de herencia.
Usando tecnicas de ORM una herencia se puede persistir usando :
table-per-class
table-per-class-hierarchy
table-per-concrete-class
En algunos framework tambien se pueden usar tecnicas mixstas.

Cual es el proceso mental que lleva a eleguir una representación en lugar que otra ?
Si las decisiones que se toman son definidas, que es lo que me impide a que sea una implementación C# la que toma esas decisiones ?

Angel "Java" Lopez

unread,
Mar 21, 2009, 7:05:49 PM3/21/09
to altnet-a...@googlegroups.com
Hola gente!
 
A ver..... En una situacion ideal (no costo en tiempo de queries o de update, sin limite de memoria en disco), todo seria igual [tengo "in pectore" un corto relato apelando a la tiotimolina sublimada de Asimov para conseguir esos efectos, guinio para @MartinSalias... ;-]
 
Como la situacion no es ideal, me imagino que los costos de cada decision se mediran en:
 
- Rendimiento de actualizacion y consulta
- Espacio de almacenamiento
 
A primera vista, me imagino que el primer punto es el mas peliaguado.
 
Sea clase Empresa, subclases Cliente, Proveedor
 
Habria que ver que consecuencias tiene entonces, el tener una tabla empresas, con un campo discriminador de si es cliente o proveedor. Que pasa si hay muchos campos en comun? O si hay muchos campos de diferencia? Pienso que mas va a influir el tema: pero queda ahi el dominio? Si el dia de maniana aparecen mas subclases, ClienteExtranjero, ProveedorExterno, no se, no se complicara el haber adoptado una sola tabla?
 
Si ponemos tablas Empresa (con los datos comunes), Clientes (con los datos adicionales), Proveedor (con los datos adicionales), habra que hilar fino en las consultas. No solo esta el tema del rendimiento de actualizacion y consulta. Tambien esta la frecuencia de algunas operaciones. Quiero decir, si una consulta determinada tarda X tiempo, habra que ponderarla tambien por la frecuencia de esa consulta en la operacion normal del sistema.
 
Con tablas Clientes, Proveedores, habra que comprobar que la actualizacion sea mas rapida que en el anterior caso. Y vigilar que pasa, y con cuanta frecuencia, se necesita una consulta sobre Empresas (que imagino debera implicar un UNION).
 
Bueno, hay tiempo para todo (Eclesiastes 3, 1-8), tiempo de comer!!!
 
Nos leemos!
 
Angel "Java" Lopez
http://www.youtube.com/watch?v=rGR8Aw0YxXo "en aquel cajon esta tu foto..."

Fabio Maulo

unread,
Mar 21, 2009, 9:58:16 PM3/21/09
to altnet-a...@googlegroups.com
Vamos vamos que eso es lo que estamos buscando...

Diagamos que cada enfoque tiene un puntaje/peso para poder tomar una decisión...
Seguimos que ese es el enfoque... pero los mails son bueno hasta allí.... no, che ?
Lucubrar juntos enfrente de un pizarrón sería mejor ;)
--
Fabio Maulo

JoseFR

unread,
Mar 22, 2009, 11:38:22 AM3/22/09
to AltNet-Argentina
Con respecto a lo de;

"che, yo tengo este dominio que tendría que persistir
en ORACLE, fijate vos! a mi lo que me interesa es que persista"

A mi me parece que a veces la "definición del dominio" debería ser MAS
COMPLETA que lo que actualmente hacemos con nhibernate por ejemplo. Y
cito un ejemplo simple de algo que me paso con fluent-automappings
probandolo hace poco,

una clase

Cuenta{
int Id
string Descripcion
Cuenta CuentaPadre
List<Cuenta> CuentasHijas
}

El caso es que para una persona es notable que cuentapadre y
cuentashijas, son la misma relación pero inversa. Para el automapping
(u otro fw/código/etc) cree que son dos cosas diferentes...

De alguna forma debería indicar EN EL DOMINIO... que CuentasHijas es
el extremo inverso de CuentaPadre.. Una forma sencilla sería mediante
atributos o con algunas convenciones.

Como en este caso se me ocurren otros, en los cuales el dominio
debería definirse de forma mas completa. Creo que estas definiciones
hoy las ponemos en los archivos hbm, como convenciones en automapping
o usando "ForTypesThatDeriveFrom" y sobreescribiendo alguna
configuración del mapeo automatico.





On 21 mar, 20:05, "Angel \"Java\" Lopez" <ajlopez2...@gmail.com>
wrote:
> Hola gente!
>
> A ver..... En una situacion ideal (no costo en tiempo de queries o de update, sin limite de memoria en disco), todo seria igual [tengo "in pectore" un corto relato apelando a la tiotimolina sublimada de Asimov para conseguir esos efectos, guinio para @MartinSalias... ;-]
>
> Como la situacion no es ideal, me imagino que los costos de cada decision se mediran en:
>
> - Rendimiento de actualizacion y consulta
> - Espacio de almacenamiento
>
> A primera vista, me imagino que el primer punto es el mas peliaguado.
>
> Sea clase Empresa, subclases Cliente, Proveedor
>
> Habria que ver que consecuencias tiene entonces, el tener una tabla empresas, con un campo discriminador de si es cliente o proveedor. Que pasa si hay muchos campos en comun? O si hay muchos campos de diferencia? Pienso que mas va a influir el tema: pero queda ahi el dominio? Si el dia de maniana aparecen mas subclases, ClienteExtranjero, ProveedorExterno, no se, no se complicara el haber adoptado una sola tabla?
>
> Si ponemos tablas Empresa (con los datos comunes), Clientes (con los datos adicionales), Proveedor (con los datos adicionales), habra que hilar fino en las consultas. No solo esta el tema del rendimiento de actualizacion y consulta. Tambien esta la frecuencia de algunas operaciones. Quiero decir, si una consulta determinada tarda X tiempo, habra que ponderarla tambien por la frecuencia de esa consulta en la operacion normal del sistema.
>
> Con tablas Clientes, Proveedores, habra que comprobar que la actualizacion sea mas rapida que en el anterior caso. Y vigilar que pasa, y con cuanta frecuencia, se necesita una consulta sobre Empresas (que imagino debera implicar un UNION).
>
> Bueno, hay tiempo para todo (Eclesiastes 3, 1-8), tiempo de comer!!!
>
> Nos leemos!
>
> Angel "Java" Lopezhttp://www.ajlopez.com/http://twitter.com/ajlopezhttp://www.youtube.com/watch?v=rGR8Aw0YxXo"en aquel cajon esta tu foto..."
>
>   ----- Original Message -----
>   From: Fabio Maulo
>   To: altnet-a...@googlegroups.com
>   Sent: Saturday, March 21, 2009 2:14 PM
>   Subject: Re: ORuM
>
>   Es largo explicarlo por mail por eso quiero sentarme con algunas mentes brillante y charlarlo.
>
>   Por un momento olvidense de NH, EF etc. tambien olvidensen de tener un DSL en el cual tengo si o si que definir representaciones que tenga a que ver con persistencia
>   Hago un ejemplo simple...
>   Tomen un eschema de herencia.
>   Usando tecnicas de ORM una herencia se puede persistir usando :
>   table-per-class
>   table-per-class-hierarchy
>   table-per-concrete-class
>   En algunos framework tambien se pueden usar tecnicas mixstas.
>
>   Cual es el proceso mental que lleva a eleguir una representación en lugar que otra ?
>   Si las decisiones que se toman son definidas, que es lo que me impide a que sea una implementación C# la que toma esas decisiones ?
>
>   El 21 de marzo de 2009 12:42, Angel "Java" Lopez <ajlopez2...@gmail.com> escribió:
>
>     Disculpen la intervencion corta: eso de "che, yo tengo este X tendria que usar Y, fijate vos!", es el leit-motiv del AjGenesis.... ;-)
>
>     Cambien X por dominio, servicios, arbol de menu, modelo en general, Y por Oracle, SQL-Server, ASP.NET MVC, PHP, IronPindongaWeb3.0#....
>
>     El "che" es una expresion italiana? ;-)
>       ----- Original Message -----
>       From: Fabio Maulo
>       To: altnet-a...@googlegroups.com
>       Sent: Saturday, March 21, 2009 11:31 AM
>       Subject: Re: ORuM
>

Fabio Maulo

unread,
Mar 22, 2009, 12:13:29 PM3/22/09
to altnet-a...@googlegroups.com
Con esa clase hay varias "cosas" por la cuales deberíamos encontrar el proceso mental que define como persistirla.
La mas simple es:
IList<Cuenta> CuentasHijas es ordenada ? le alcanza un <bag> o debería ser un <list> ?
si <bag> o <list> es arbritario o tiene logica ?

Para descubrir una relación inversa hago un ejemplo que es mas facil describir:
OrdenCompra - OrdenCompraItem

Si OrdenCompra tiene un IEnumerable<OrdenCompraItem> y OrdenCompraItem tiene una propiedad de tipo OrdenCompra se aplica one-to-many + many-to-one + "inverse".

En tu caso sería
Si Cuenta tiene un IEnumerable<Cuenta> y Cuenta tiene una propiedad de tipo Cuenta se aplica "inverse". (o sea que se aplicaría)

Mirando la clase, como se hace a descrubrir si OrdenCompraItem es un components o una entity ? 
que puntaje tiene cada Match para definir la representation final ?
Cuales son las decisiones realmente arbitrarias ?

Si tengo un eschema de herencia que involucra 9 classes y llega a 3 niveles (A<-A1<-A2, A<-B, A<-C<-C1, A<-D, A<-E<-E1) cuales son los requisitos que me llevan a decidir de usar (por brevedad hago ejemplos con tags de NH):
<subclass>
<subclass><join>
<joined-subclass>
<union-subclass>
Cuanto pesa el requisito "La clase B va a tener un millón de instancias" respecto a que "La clase E1 tiene 40 propiedades de la cuales 10 son relaciones con otras entidades" o respecto a que "Las interrogaciones de una rama de herencia nunca se van a mezclar con otra rama".
--
Fabio Maulo

JoseFR

unread,
Mar 22, 2009, 1:10:15 PM3/22/09
to AltNet-Argentina
> En tu caso sería
> Si Cuenta tiene un IEnumerable<Cuenta> y Cuenta tiene una propiedad de tipo
> Cuenta se aplica "inverse". (o sea que se aplicaría)

Y qué haríamos si cuenta tiene dos propiedades Cuenta, digamos
CuentaPadre y CuentaDeReversion. Obviamente la segunda no tiene nada
que ver con CuentasHijas.

Con respecto al ejemplo de herencia otro factor que podría influir es
si necesitamos que las propiedades de las sub clases no permitan
nulos, en este caso subclass (es decir Table per class hierarchy) no
es aplicable. Si las hijas solo poseen propiedades nullables (int?,
string?..blabla), podría usarse TCH. (se me ocurre al vuelo, es esto
a caso un brainstoriming?)
A no ser que..............A nivel bd TODO permita valores nulos y el
framework maneje en otro nivel de asbtracción cuando un valor del
dominio pueda o no tener nulo.


On 22 mar, 13:13, Fabio Maulo <fabioma...@gmail.com> wrote:
> Con esa clase hay varias "cosas" por la cuales deberíamos encontrar el
> proceso mental que define como persistirla.La mas simple es:
> >www.ajlopez.com/http://twitter.com/ajlopezhttp://www.youtube.com/watc..."en

Fabio Maulo

unread,
Mar 22, 2009, 1:57:51 PM3/22/09
to altnet-a...@googlegroups.com
El 22 de marzo de 2009 14:10, JoseFR <jfroma...@gmail.com> escribió:

> En tu caso sería
> Si Cuenta tiene un IEnumerable<Cuenta> y Cuenta tiene una propiedad de tipo
> Cuenta se aplica "inverse". (o sea que se aplicaría)

Y qué haríamos si cuenta tiene dos propiedades Cuenta, digamos
CuentaPadre y CuentaDeReversion. Obviamente la segunda no tiene nada
que ver con CuentasHijas.

Con respecto al ejemplo de herencia otro factor que podría influir es
si necesitamos que las propiedades de las sub clases no permitan
nulos, en este caso subclass (es decir Table per class hierarchy) no
es aplicable. Si las hijas solo poseen propiedades nullables (int?,
string?..blabla), podría usarse TCH.  (se me ocurre al vuelo, es esto
a caso un brainstoriming?)
A no ser que..............A nivel bd TODO permita valores nulos y el
framework maneje en otro nivel de asbtracción cuando un valor del
dominio pueda o no tener nulo.


Yo creo que hay muchisimos casos que no son "arbitrarios".

Para lo de subclass... un int, en la clase, no es nullable y en la tabla puede tener un default de todas forma el "Si tiene nullables" es un requisito con su peso pero es solo un requisito entre otros.

Para lo de la doble referencia (CuentaPadre y CuentaDeReversion) no hay mucho que peliarse ya que será siempre una many-to-one y el inverse trabaja en la collection; la decisión es sobre cual es el nombre del campo que define la relación Padre-Hijas.
Supongamos que no hay forma de calcularlo (repito supongamos), en ese caso se necesita una definición arbritaria y el framework no pide el "link" entre propiedades
Relate(x => x.CuentasHijas).On(x => x.CuentaPadre)
Pero podría ser tambien
ParentChild.Where.Children(prop => prop.Name.EndWith("Hijas")).And.Parent(prop => prop.Name.EndWith("Padre");

Estan podrian ser "escapatoias" para los casos realmente arbritrarios donde no se logra, por ahora, descubrir relaciones sin la intervención explicita del programador.

El objetivo de ORuM no es el "AutoMapping" de FNH y tampoco es definir un DSL para mapear; el objetivo es usar un Framework de persistencia como si fuese un Object Oriented Data Base (el dasafio es que las entidades se guardan en un RDBMS).

--
Fabio Maulo

Dario Quintana

unread,
Mar 22, 2009, 2:34:56 PM3/22/09
to altnet-a...@googlegroups.com
Bien.

La idea es como dice Fabio, persistir entidades, sin preocuparnos de detalles. Hay caraterísticas del modelo que nos van a permitir ponderar sobre qué estrategias de Herencia, Colección (Asociación), etc elegir.

A simple vista, charlando un poco, se pueden distinguir, entre las carateristicas que nos ayudan a la ponderacion:
- Explícitas (en el modelo): son evidentes, y se pueden inferir solamente mirando el modelo.
- De uso (del modelo): no son evidentes en el modelo, o no tanto, pero sí son evidentes si se sabe cómo se pretende usar (mayoritariamente) el modelo.


2009/3/22 Fabio Maulo <fabio...@gmail.com>

Angel "Java" Lopez

unread,
Mar 22, 2009, 4:29:44 PM3/22/09
to altnet-a...@googlegroups.com

JoseFR

unread,
Mar 22, 2009, 5:51:47 PM3/22/09
to AltNet-Argentina
Ya estoy entendiendo mejor a donde queres llegar Fabio y coincido con
Dario. Debe ser por que estoy tomando mate.

La cuestión a la que quería llegar era esta, se que un alto porcentaje
de caracteristicas son Explicitas. De algunas que hablamos voy a decir
cuales me parecen de una y cuales de otra:


-Explicitas:
* "La clase E1 tiene 40 propiedades de la cuales 10 son relaciones
con otras entidades" (Fabio)
** Me parece explicita por que no hace falta agregar nada con
una simple mirada al dominio sabemos que propiedades tiene
(reflection).
* "si se detectan excesiva cantidad de diferencias (> 10, por tirar
un número) entre una super-class y una sub-class, descartar el elegir:
table-per-class-hierarchy" (Dario)
** Idem que la anterior

-De uso:
* "La clase B va a tener un millón de instancias" (Fabio)
** ¿ como y donde defino esto ? ¿ hace falta definirlo en el
dominio? (se me ocurre una media alocada: la herramienta podría
detectar el crecimiento, alterar el esquema, migrar los datos del
viejo al nuevo esquema)
** O podría estar definido en el dominio..
** O podría estar definida como una configuración
** Como una convención no me gusta.

* "Cuenta: CuentaPadre CuentaDeReversion y CuentasHijas, 2
propiedades del tipo Cuenta y 1 del tipo List Generica<Cuenta>, la
primera es inversa a la tercera, y la segunda no tiene lado inverso.
(yo)
** En este caso, me parece que sería valido tener definido en el
propio dominio, quizas como atributo que CuentasHijas es el lado
opuesto de CuentaPadre. Mas alla de nhibernate/EF/FNH etc.. .A mi me
parece que esto le concierne al dominio
** O definirlo como una configuración en otro lugar.
** O como una convención, (termina con "Padre" y termina con
"Hijas"
** Que existan realmente 3 claves foraneas, al cambiarle el
padre a una cuenta actualizar las dos colecciones de cuentas hijas (de
la nueva CuentaPadre y de la vieja CuentaPadre). Evidentemente esta
opción es la peor, redundancia de datos y laburo extra.





On 22 mar, 15:34, Dario Quintana <conta...@darioquintana.com.ar>
wrote:
> Bien.
>
> La idea es como dice Fabio, persistir entidades, sin preocuparnos de
> detalles. Hay caraterísticas del modelo que nos van a permitir ponderar
> sobre qué estrategias de Herencia, Colección (Asociación), etc elegir.
>
> A simple vista, charlando un poco, se pueden distinguir, entre las
> carateristicas que nos ayudan a la ponderacion:
> - Explícitas (en el modelo): son evidentes, y se pueden inferir solamente
> mirando el modelo.
> - De uso (del modelo): no son evidentes en el modelo, o no tanto, pero sí
> son evidentes si se sabe cómo se pretende usar (mayoritariamente) el modelo.
>
> 2009/3/22 Fabio Maulo <fabioma...@gmail.com>

Fabio Maulo

unread,
Mar 22, 2009, 6:15:27 PM3/22/09
to altnet-a...@googlegroups.com
Angel.. lo que yo he visto es "mapeo a instinto" o "adaptación a lo que dice el DBA" (cuando hay un DBA).
Yo espero llegar a tener un check-list, tipo lo que tienen los aviones cuando aparece una crisis, para poder definir un mapping, y espero tener "algo" que muestre el camino sobre la base de la experiencia de N gurues y N*X resultados obtenidos en sistemas andando.
De no ser así veo dos caminos:
- los OODB tengan exito y prestaciones mejores de los RDBMS
- logramos "encontrar la manera de garantizar energia, en forma permanente, a nuestros servidores" así tendremos todas las instancias en RAM.

P.S. a ver si te suena la segunda opción.

--
Fabio Maulo

Angel "Java" Lopez

unread,
Mar 22, 2009, 6:32:16 PM3/22/09
to altnet-a...@googlegroups.com
Claro, lo que digo que esa lista solo se podra aplicar en un sistema experto. No veo que un modelo sencillo, con anotaciones o algunas cosas mas, como decisiones por convencion, baste para aplicar lo que descubramos. Pero esa es una postura personal mia.
 
Jeje.... la segunda opcion, si, me suena, gracias por recordarlo... Has visto la luz! ;-)... como en http://fabiomaulo.blogspot.com/2008/12/light.html
 
;-)
 
Siempre nos queda GemStone.... o AjTalk .. ;-)

Fabio Maulo

unread,
Mar 22, 2009, 6:43:15 PM3/22/09
to altnet-a...@googlegroups.com

Claudio Meschini

unread,
Mar 22, 2009, 6:50:47 PM3/22/09
to altnet-a...@googlegroups.com
Muchos temas para comentar ;)

Empecemos por el modelo, coincido con Angel, el modelo es mas que el conjunto de clases, así esta pensado Quetzal, pero las clases del dominio son para mi el "core" del modelo. Dicho de otro modo para simplificar, al modelo se lo puede "deducir" con info que viene de las clases (por reflection) y en segundo lugar por metadata. Donde definir esa metadata y como extenderlo es otro tema (atributos, configuracion, clases asociadas, DSL, etc) . Ademas esta metadata deber ser facilmente extensible. Esto es central para tener una forma de definir las partes "arbitrarias" del modelo, es decir aquellas partes que no se pueden deducir y donde entra el "saber" del programador para tomar un camino u otro.

Pero queda un tema más en como "deducir" el modelo, y aca entramos en otro tema: como "marcamos" el modelo (clases/metadata). Voy a tratar de ser mas claro: como distingo si una clase debe ser persistida como un  componente  o un "many-to-one"? Para "mi" modelo busco en la clase si posee una propiedad "Id" si existe es un "many-to-one" sino es un componente. Alguien se podría preguntar y como distingo el ID? Por "convención": si una propiedad se llama "Id" o "Id" + nombre de la clase: es un ID. Pero por otro lado ese es "mi" modelo, y esas son "mis" reglas para deducirlo. Este es un punto que quiero mejorar cuando tenga tiempo en Quetzal que el modelo tenga una lista de "reglas asociadas" para deducirlo y que cada uno lo configure como quiere. Ahora la forma de deduccion es fija, esta "hardcodeada".  Acá Angel podría poner su motor de reglas basado en IA. Inclusive trabajar con una librería con clases basicas para el dominio que incluyan definiciones de persona, telefono etc. Esto permitira tambien tener como definidos un conjunto de reglas que permitirían cambiar la forma de "entender" el modelo y variar sus output: reglas para clases con mas de 40 propiedades y 3 niveles de herencia, etc, O reglas de acuerdo al Guru que uno siga) ;)

La corto acá, para no cansar.

Saludos, Claudio.
claudiomeschini.blogspot.com

Dario Quintana

unread,
Mar 22, 2009, 7:47:27 PM3/22/09
to altnet-a...@googlegroups.com
Acá entramos en otra cosa, que me hizo acordar Claudio, qué quizas no haya una forma única de "mapear" algo, pero nosotros debemos elegir cuál es la más eficiente, cómo quede el modelo relacional, hasta pareciera que no importa, siempre y cuando cuando "yo" usuario necesito realizar una consultas por medio de la API Y, pueda hacerla basandome en el modelo de objetos.

A parte, otra cosa, hasta ahora venimos poniendo la palabra Id, pero, el Id puede ser explícito o no. Dicho de otra manera, yo puedo guardar el objeto, que tenga un Id o no, realmente no me interesa, si lo tiene, es por que está asociado al objeto, no por que el objeto lo tenga que tener definido en su clase.
Y yendo por el mismo lado, este motor puede hasta llegar a tratar arrays de enteros, como first class objects, y esto es todo un tema.

Con esto podemos a llegar a la conclusión de que los objetos, tal como los tenemos en el CLR no se almacenen exactamente como los conocemos, tiene que tener sus matices para poder manejar a los objetos dentro de tablas.

2009/3/22 Claudio Meschini <cmes...@gmail.com>

Fabio Maulo

unread,
Mar 22, 2009, 7:47:50 PM3/22/09
to altnet-a...@googlegroups.com
Te la complico un poco:
Yo tengo entidades sin propiedad ID.

Pero estamos siempre en la misma hay que sentarse y charlar.

Los criterios "arbritario" definen el camino o solo hacen mas "pesando" un camino en lugar que otro ?
--
Fabio Maulo

JoseFR

unread,
Mar 22, 2009, 9:03:25 PM3/22/09
to AltNet-Argentina
Quizas sea una obviedad lo que voy a decir, pero el concepto de ID-
claveprimaria es totalmente relacional. (de clave foranea ni hablar)

Cualquier dato en una bd relacional puede ser accedido a traves de
clave primaria de la entidad + nombre de campo..yadda yadda, el modelo
relacional necesita claves primarias.

En el modelo OO no. Pero de alguna forma necesitamos obtener una
instancia.. en sharp architecture hay algo que se usa para los
equality members, llamado 'domaing signature'. Dos objetos son iguales
si tienen la misma 'domaing signature', que es un atributo o conjunto
de ellos.



On 22 mar, 20:47, Fabio Maulo <fabioma...@gmail.com> wrote:
> Te la complico un poco:Yo tengo entidades sin propiedad ID.http://fabiomaulo.blogspot.com/2008/11/entities-behavior-injection.html
>
> Pero estamos siempre en la misma hay que sentarse y charlar.
>
> Los criterios "arbritario" definen el camino o solo hacen mas "pesando" un
> camino en lugar que otro ?
>

Claudio Meschini

unread,
Mar 22, 2009, 9:47:47 PM3/22/09
to altnet-a...@googlegroups.com
Concuerdo con Dario, un framework que suplante los hbm debería contemplar desde una autoconfiguración con todo seteado por default hasta darle al usuario la posibilidad de "customizar" sus mappings lo máximo posible como lo puede hacer con los xml.

Tambien acuerdo en lo que dice Jose y Darío, ponemos en nuestra clases de dominio propiedades que no corresponden con un desarrollo OO sino con necesidades de infraestructura (Constructores sin parametros, ids) . De esa forma estamos "acoplando" nuestro dominio a algún framework. Mi idea siempre fue poder partir de "cualquier" assembly o subconjunto de clases que representara el dominio y generar todo lo que fuera necesario: vistas, hbm's, validadores, etc. sin tocarlo. Por eso no fui por el lado de extender Quetzal mediante atributos porque hubiese significado obligar a reescribir los dominio de las aplicaciones que lo utilizaran. Si se necesita mas información para obtener un comportamiento o un seteo (por ej. el length de un campo string) este debe venir provisto por la metadata de la clase. Fijense que de alguna forma los hbm a veces funcionan como proveedores de la metadata para resolver la "impedancia" entre el modelo relacional y el de objetos

Claudio

Dario Quintana

unread,
Mar 22, 2009, 11:09:29 PM3/22/09
to altnet-a...@googlegroups.com
Si, eso pasa en los RDBMS, estamos tratando de trabajar sobre ellos, hay que usarlos, nadie dice lo contrario.
En mi mail anterior hay una linea que quizas es un poco tímida, pero cuando me refería que podría tener arrays de enteros como first class objects, por dar un ejemplo, podríamos hablar de cualquier tipo de objeto, me estaba refiriendo a hacer esto:

contenedor.Persist(new int[101]);

ó

cuando hago save de una clase como esta:
class MiEntidad
{
     string Descripcion {get;set;}
     decimal[] ValoresVarios {get;set}
}

el Save lo realizo así:
contenedor.Persist(miEntidad);

Luego, podría hacer una aserción de este tipo:
Assert(contenedor.Query<decimal[]>().List().Count,1);

Y ahí ? Agarrate Catalina :-) Bueno, eso expresa un poco mi idea.

En conclusión, haganse la idea de que queremos hacer un ODBMS, pero sin tener que usar System.IO, queremos tener la teoria para poder persistir objetos, como ciudadanos de primera clase, en bases de datos relacionales.

2009/3/22 JoseFR <jfroma...@gmail.com>


Quizas sea una obviedad lo que voy a decir, pero el concepto de ID-
claveprimaria es totalmente relacional. (de clave foranea ni hablar)

Cualquier dato en una bd relacional puede ser accedido a traves de
clave primaria de la entidad + nombre de campo..yadda yadda, el modelo
relacional necesita claves primarias.

En el modelo OO no. Pero de alguna forma necesitamos obtener una
instancia.. en sharp architecture hay algo que se usa para los
equality members, llamado 'domaing signature'. Dos objetos son iguales
si tienen la misma 'domaing signature', que es un atributo o conjunto
de ellos.

Claudio Meschini

unread,
Mar 22, 2009, 11:31:39 PM3/22/09
to altnet-a...@googlegroups.com
En conclusión, haganse la idea de que queremos hacer un ODBMS, pero sin tener que usar System.IO, queremos tener la teoria para poder persistir objetos, como ciudadanos de primera clase, en bases de datos relacionales.

Me imagino que como no piensan ni en serializacion XML ni en mapear cada par propiedad/valor de una clase a una tabla con dos columnas, se me hace dificil pensar que otra cosa pueda existir.

En que estan pensando?

Claudio

Fabio Maulo

unread,
Mar 23, 2009, 12:50:20 AM3/23/09
to altnet-a...@googlegroups.com
El 23 de marzo de 2009 0:31, Claudio Meschini <cmes...@gmail.com> escribió:

En que estan pensando?

Espero que ese plural no me incluya.

--
Fabio Maulo

JoseFR

unread,
Mar 23, 2009, 7:54:08 AM3/23/09
to AltNet-Argentina
Assert(contenedor.Query<decimal[]>().List().Count,1); -> Para mi
debería fallar, dado que en los dos ejemplos que diste antes no
persististe ningun array de decimales.

Persistis miEntidad y un int[]
Assert(contenedor.Query<miEntidad>().List().Count, 1);
Assert(contenedor.Query<int[]>().List().Count, 1);


O debería pasar el test por que persististe una miEntidad que tiene un
array de decimales como propiedad...?



On 23 mar, 00:09, Dario Quintana <conta...@darioquintana.com.ar>
wrote:
> Si, eso pasa en los RDBMS, estamos tratando de trabajar sobre ellos, hay que
> usarlos, nadie dice lo contrario.
> En mi mail anterior hay una linea que quizas es un poco tímida, pero cuando
> me refería que podría tener arrays de enteros como first class objects, por
> dar un ejemplo, podríamos hablar de cualquier tipo de objeto, me estaba
> refiriendo a hacer esto:
>
> contenedor.Persist(new int[101]);
>
> ó
>
> cuando hago save de una clase como esta:
> class MiEntidad
> {
>      string Descripcion {get;set;}
>      decimal[] ValoresVarios {get;set}
>
> }
>
> el Save lo realizo así:
> contenedor.Persist(miEntidad);
>
> Luego, podría hacer una aserción de este tipo:
> Assert(contenedor.Query<decimal[]>().List().Count,1);
>
> Y ahí ? Agarrate Catalina :-) Bueno, eso expresa un poco mi idea.
>
> En conclusión, haganse la idea de que queremos hacer un ODBMS, pero sin
> tener que usar System.IO, queremos tener la teoria para poder persistir
> objetos, como ciudadanos de primera clase, en bases de datos relacionales.
>
> 2009/3/22 JoseFR <jfromanie...@gmail.com>

Martín Salías

unread,
Mar 23, 2009, 8:39:05 AM3/23/09
to altnet-a...@googlegroups.com
Coincido con Fabio, y creo que es hora de que vayamos pensando lugar y fecha del primer Open Space.

Me encantó el tema y ¡quiero pizarrón!

Yo escucho esto y pienso en matrices estocásticas y comportamiento adaptativo... y espero que @ajlopez se levante de su escritorio y venga a traerme la pastilla roja y el vaso de agua... :)

Arranco un thread aparte para empezar a melonear la reunión.

Saludos,
---
Martín Salías
http://blog.Salias.com.ar



2009/3/21 Fabio Maulo <fabio...@gmail.com>

Claudio Meschini

unread,
Mar 23, 2009, 9:07:24 AM3/23/09
to altnet-a...@googlegroups.com
Es un plural generico porque Dario lo puso así: "haganse la idea de que QUEREMOS hacer un ODBMS". Simple retorica.

Saludos, Claudio.

Daniel Calvin

unread,
Mar 23, 2009, 9:54:33 AM3/23/09
to altnet-a...@googlegroups.com
Vengo leyendo a mil, pero no puedo dejar de descubrir, mas alla de la herramienta o framework subyacente, los problemas que queremos resolver.

>>>>>
En este caso, me parece que sería valido tener definido en el
propio dominio, quizas como atributo que CuentasHijas es el lado
opuesto de CuentaPadre. Mas alla de nhibernate/EF/FNH etc.. .A mi me
parece que esto le concierne al dominio
     ** O definirlo como una configuración en otro lugar.
     ** O como una convención, (termina con "Padre" y termina con
"Hijas"
>>>>>

El problema con que me encuentro yo al ver estas cosas es el siguiente, y para mi aparece mucho antes de llegar al modlo relacional, ciclo de vida de los objetos.

En una base de datos mediante PK y FKs defino dependencia y navegación bidireccional, en el modelo de objetos puedo llegar a definir la composición ( sea un Agregate o un Composite, siempre según el concepto UML ), el ciclo de vida se puede llegar a inferir, la navegación hay que declararla.

La cuestión es entonces si un framework de este tipo cuenta con todo lo necesario para inferir, yo creo que no, porque el modelo aunque se quiera no es auto descriptivo.
Ej.
Factura
LineasDeFactura[]

Si conozco el dominio puedo decir que el ciclo de vida de una linea de factura esta totalmente asociado a el ciclo de vida la factura.

Grupo
Personas[]

En este caso posiblemente las personas existan más allá d ela existencia del grupo.

Según UML el primero es un Composite, el segungo un Agregatte.

Si hago ing. inversa de las clases y no hay metadata esos detalles no los puedo inferir.
Ahora, si esa metadata es necesaria y describe el dominio, esta mal pensar en esa metadata como adornos a las clases?, es invasivo?, produce acoplamiento??
Yo creo que no, es metadata del dominio.

La venataja que da tomar eso como metadata es que expresa algunas cuestiones que puden facilitar el camino al modelo relacional sin hacer uso de los conceptos relacionales.

No se si transmito la idea con claridad, que opinan.


Daniel Calvin
PD: Esto lo vengo persiguiendo desde hace 6 años aprox.
--
Daniel A. Calvin
Cooperator Team Member
http://www.cooperator.com.ar
Microsoft Certified Professional

Fabio Maulo

unread,
Mar 23, 2009, 10:02:00 AM3/23/09
to altnet-a...@googlegroups.com
Opino que nos tenemos que sentar a charlar ;)
--
Fabio Maulo

Diego Jancic

unread,
Mar 23, 2009, 10:08:39 AM3/23/09
to altnet-a...@googlegroups.com
Hola Daniel,
Creo que tenes mucha razon en eso... hay metadata que es imposible de
sacar de las clases, lo mismo pasa cuando tenemos 2 many-to-many entre
2 clases, de cada lado esta representado por 2 colecciones. Lo que no
se puede saber es cual corresponde con cual.

De lo que no estoy seguro es si esa metadata deberia estar en las
clases, yo creo que no porque si bien en algunos casos esta bien (como
en el ejemplo que diste vos), existe mucha otra metadata necesaria
para generar codigo que no corresponde al dominio.
Existe metadata que tiene que ver con UI o con persistencia, pero esta
estrictamente relacionada con un objeto del dominio.

Por lo tanto creo que, o la metadata se expresa en cada componente que
la necesite (ej: hbms), o se guarda en algun lugar separado al dominio
que contenga toda la metadata necesaria: en el caso de un generador de
codigo, seria éste el que guardaria la informacion.

Saludos!
Diego

2009/3/23 Daniel Calvin <daniel...@gmail.com>:

Dario Quintana

unread,
Mar 23, 2009, 10:16:21 AM3/23/09
to altnet-a...@googlegroups.com
Hola Daniel

Si estamos hablando de los objetos más allá de la memoria, la metadata de la que hablás se plasma en el motor de persistencia, Db4o lo trabaja así si mal no recuerdo.

2009/3/23 Daniel Calvin <daniel...@gmail.com>

JoseFR

unread,
Mar 23, 2009, 10:18:21 AM3/23/09
to AltNet-Argentina
Fabio, en este hilo mencionaste las palabras "Gurues" y "mentes
brillantes", y yo creo que no entro en nignuna de las dos categorías.
Es excluyente para la reunión?



On 23 mar, 11:02, Fabio Maulo <fabioma...@gmail.com> wrote:
> Opino que nos tenemos que sentar a charlar ;)
>
> > El 22 de marzo de 2009 22:47, Claudio Meschini <cmesch...@gmail.com>escribió:
>
> > Concuerdo con Dario, un framework que suplante los hbm debería contemplar
> >> desde una autoconfiguración con todo seteado por default hasta darle al
> >> usuario la posibilidad de "customizar" sus mappings lo máximo posible como
> >> lo puede hacer con los xml.
>
> >> Tambien acuerdo en lo que dice Jose y Darío, ponemos en nuestra clases de
> >> dominio propiedades que no corresponden con un desarrollo OO sino con
> >> necesidades de infraestructura (Constructores sin parametros, ids) . De esa
> >> forma estamos "acoplando" nuestro dominio a algún framework. Mi idea siempre
> >> fue poder partir de "cualquier" assembly o subconjunto de clases que
> >> representara el dominio y generar todo lo que fuera necesario: vistas,
> >> hbm's, validadores, etc. sin tocarlo. Por eso no fui por el lado de extender
> >> Quetzal mediante atributos porque hubiese significado obligar a reescribir
> >> los dominio de las aplicaciones que lo utilizaran. Si se necesita mas
> >> información para obtener un comportamiento o un seteo (por ej. el length de
> >> un campo string) este debe venir provisto por la metadata de la clase.
> >> Fijense que de alguna forma los hbm a veces funcionan como proveedores de la
> >> metadata para resolver la "impedancia" entre el modelo relacional y el de
> >> objetos
>
> >> Claudio
>
> >> El 22 de marzo de 2009 20:47, Dario Quintana <
> >> conta...@darioquintana.com.ar> escribió:
>
> >> Acá entramos en otra cosa, que me hizo acordar Claudio, qué quizas no haya
> >>> una forma *única* de "mapear" algo, pero nosotros debemos elegir cuál es
> >>> la más eficiente, cómo quede el modelo relacional, hasta pareciera que no
> >>> importa, siempre y cuando cuando "yo" usuario necesito realizar una
> >>> consultas por medio de la API Y, pueda hacerla basandome en el modelo de
> >>> objetos.
>
> >>> A parte, otra cosa, hasta ahora venimos poniendo la palabra *Id*, pero,
> >>> el Id puede ser explícito o no. Dicho de otra manera, yo puedo guardar el
> >>> objeto, que tenga un Id o no, realmente no me interesa, si lo tiene, es por
> >>> que está asociado al objeto, no por que el objeto lo tenga que tener
> >>> definido en su clase.
> >>> Y yendo por el mismo lado, este motor puede hasta llegar a tratar arrays
> >>> de enteros, como first class objects, y esto es todo un tema.
>
> >>> Con esto podemos a llegar a la conclusión de que los objetos, tal como
> >>> los tenemos en el CLR no se almacenen exactamente como los conocemos, tiene
> >>> que tener sus matices para poder manejar a los objetos dentro de tablas.
>
> >>> 2009/3/22 Claudio Meschini <cmesch...@gmail.com>
> ...
>
> leer más »

Carlos Peix

unread,
Mar 23, 2009, 10:20:40 AM3/23/09
to AltNet-Argentina
Hola gente,

Una manera piola de especificar metadata que, a mi juicio, va muy bien
con el modelo de framework "vos hace todo que si tengo algo particular
te aviso" son los descriptors (no estoy seguro de que esto sea un
patron).

La idea, mas o menos, es asi: el framework funciona solo, seria bueno
que con reglas generales injectables. Si tengo que corregir algun
comportamiento, creo una clase mas o menos asi:

public class PersonaPersistenceDescriptor : PersistenceDescriptor
{
// Esto es solo una propuesta, eguramente que alguien que sepa mas
de
// C# 3.0 o 4.0 va a sugerir algo mejor.
public override Type GetDescriptedType()
{
return typeof(Persona);
}

// Aqui vendrian los metodos que corrigen el comportamiento normal
del
// framework, por ejemplo.

}

El framework se encargaria de instanciar todas las clases que deriven
de PersistenceDescriptor y registrarlas llamando al metodo
GetDesriptedType(). Otra opcion es que la clase se autoregistre.

Carlos Peix

Daniel Calvin

unread,
Mar 23, 2009, 10:23:02 AM3/23/09
to altnet-a...@googlegroups.com
Uhmmm,

Bárbaro lo que decis, pero, tipo fanático yo....
Cual es mi vision?
Si necesito metadata para la UI y la meto en el dominio, uhmmm
O, según tu planteo, no la meto en e dominio pero la meto en un repositorio comun a toda la metadata. otro uhmmm...

Y si voy a hacer remoting? o ws?, no necesitate otra metadata especifica tambien?, o workflow? o alguna otra cosa que saque ventaja de la metadata?

Entonces agarro mi algunFile.metadata y meto todo ( me quedo redundante... )

La cuestión creo es respetar los mismos principios que se respetan para hacer OOD.

Experto en información
Alta cohesión
Bajo acoplamiento

Pero esto orientado a la metadata, divide y triunfarás?

Imaginate toda la metadata en el mismo lugar, ya me duele la cabeza de tratar de entender que cosa se refiere a que...

Ojo, puedo estar equivocado, pero pensa que uno a mi edad es muy estructurado.

Se entiende la idea de división de metadata según su tipo o capa?, esa me parece la mejor solución, además facilitaría la extensibilidad...

Pero bueno, son ideas en el aire, tal vez ejemplificando un poco se puede mejorar.
( sea un caso u otro )
Yo soy un poco fanático de separar las cosas lo mas posible, hay una expresión, EL MODELO HUELE , en mi imagen mental me gustaría que la metadata no HUELA.


Daniel

Daniel Calvin

unread,
Mar 23, 2009, 10:29:08 AM3/23/09
to altnet-a...@googlegroups.com
Hablo de los objetos, mas alla de su persitencia, diría yo...
Por eso fijate que hablo de conceptos de modelado de objetos, que podrían incluso no persistirse jamas.
Lo que digo es que en definitiva si se quiere llevar algo al modelo relacional y estos adornos existen se pueden aprovechar y lo bueno es que no estan expresados en términos de persistencia, solo en ciclo de vida y el ciclo de vida no es un concepto de persistencia.

Digamos que me pongo de costado para mirarlo de ese punto de vista y como que se ven algunas cosas que desde el frente no veo.

Daniel

Dario Quintana

unread,
Mar 23, 2009, 10:44:58 AM3/23/09
to altnet-a...@googlegroups.com
Ah!, yo le agarré con inercia a tu mail, por que siempre hablábamos de persistencia.

2009/3/23 Daniel Calvin <daniel...@gmail.com>

Hablo de los objetos, mas alla de su persitencia, diría yo...
Por eso fijate que hablo de conceptos de modelado de objetos, que podrían incluso no persistirse jamas.
Lo que digo es que en definitiva si se quiere llevar algo al modelo relacional y estos adornos existen se pueden aprovechar y lo bueno es que no estan expresados en términos de persistencia, solo en ciclo de vida y el ciclo de vida no es un concepto de persistencia.

Digamos que me pongo de costado para mirarlo de ese punto de vista y como que se ven algunas cosas que desde el frente no veo.

Daniel

Daniel Calvin

unread,
Mar 23, 2009, 10:50:55 AM3/23/09
to altnet-a...@googlegroups.com
Noo ta bien, se hace medio dificil algunas veces, uno tiene la idea en mente y la cuenta apurado... el resto no es adivino.

Fijate el otro email que respondo sobre Diego Jancic, creo que era el , ahi tratao de aclarar un poco mas la idea... o la confundirla un poco mas... ja ja

Daniel