ORuM

[Fabio Maulo]

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]

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]

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

http://fabiomaulo.blogspot.com/2008/11/mapping-source-how-map-class-without.html

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

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

[Dario Quintana]

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]

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]

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]

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]

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]

Solo para avisar...

En el curso del dia tomo mate... alchol solo a la noche.

--
Fabio Maulo

[Fabio Maulo]

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:

http://fabiomaulo.blogspot.com/2008/10/less-than-gof-is-hbm.html

 

 

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]

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]

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]

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]

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.ajlopez.com/

http://twitter.com/ajlopez

http://www.youtube.com/watch?v=rGR8Aw0YxXo "en aquel cajon esta tu foto..."

[Fabio Maulo]

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]

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]

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]

> 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]

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]

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]

Loosely related

http://msmvps.com/blogs/lopez/archive/2009/03/22/modelo-decisiones-inteligencia-artificial-y-ajgenesis.aspx

 

Angel "Java" Lopez

http://www.ajlopez.com/

http://twitter.com/ajlopez

 

[JoseFR]

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]

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]

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]

Tabien alguien mas

http://fabiomaulo.blogspot.com/2009/02/light-working.html

--
Fabio Maulo

[Claudio Meschini]

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]

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]

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 ?

--
Fabio Maulo

[JoseFR]

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]

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]

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]

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]

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]

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]

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]

Es un plural generico porque Dario lo puso así: "haganse la idea de que QUEREMOS hacer un ODBMS". Simple retorica.

Saludos, Claudio.

[Daniel Calvin]

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]

Opino que nos tenemos que sentar a charlar ;)

--
Fabio Maulo

[Diego Jancic]

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]

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]

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]

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]

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]

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]

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]

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

[Fabio Maulo]

El 23 de marzo de 2009 11:18, JoseFR <jfroma...@gmail.com> escribió:

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?

Y a esto como contesto ?

La respuesta verdadera te la doy a la charla, por ahora te digo que no es escluyente.

--
Fabio Maulo

[Claudio Meschini]

Daniel:

Te contesto entrelineado:

Si necesito metadata para la UI y la meto en el dominio, uhmmm

No, la metadata no es parte del dominio, pero si parte del modelo. Coincido

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?

Seguro, que necesitas metadata especifica, y para eso tiene que  ser facil extender el modelo.

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

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

Y la metadata tiene que estar organizada por "temas", porque en un modelo puede necesitar metadata para NH pero no para Workflow. Pero tambien tiene que tener cierta cohesión por ejemplo: el "length" de un string me puede servir para persisitencia y tambien para la UI, por eso la metadata tiene que tener cierta cohesión.

En Quetzal yo me refiero a cada tema de la metadata así:

model.Ext<Empresa,NHExtensionClass>().Table = "TableEmpresa"

model.Ext<Empresa, ValidateExtensionClass>().AddRule(new ValidaEmpresa(), "La empresa no es válida");

Saludos, Claudio

Pd.: no me gusta el autobombo pero si tienen tiempo dense una vuelta por el codigo de Quetzal que ahi por lo menos sostengo con codigo lo que digo.
 

[Diego Jancic]

Cuando tenes razon, tenes razon...
Lo unico que decia es de no poner la metadata en el dominio, al menos
no TODA la metadata... donde deberia ir es otra cuestion..

> 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...

Puede funcionar, el tema es que pasa cuando la misma metadata se usa
en multiples niveles? Por ejemplo el largo maximo de un campo, lo
usas en la UI para validar, lo usas en la base de datos, lo usas en
algun servicio seguramente para validar, y seguramente muchos otros
lugares..

Entonces no se si el criterio de dividir es tan claro, aunque creo que
si se define un buen criterio puede funcionar...

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

[Fabio Maulo]

Si es claro ;)

Justo tocaste un cross-cutting-concern que es la validación por constraints (como la longitud de una propiedad string)

NHV te recuerda algo ?

--
Fabio Maulo

[Daniel Calvin]

Hola Claudio

Muy bien tus correciones, >>>la metadata no es parte del dominio, pero si parte del modelo.
Voy a pegarle una miradita, no lo veo como autobombo, esta muy bien tu propuesta.


Daniel

[Daniel Calvin]

Diego,

Seguro no es fácil, pero ...

El 23 de marzo de 2009 12:02, Diego Jancic <jan...@gmail.com> escribió:

[JoseFR]

Bueno, me parece que se desvio totalmente la conversación, por que en
vez de ver donde poner la "metadata" ... Hay que ver de que metadata
estamos hablando. Yo lo que propuse antes era "completar la definición
del dominio en el modelo" para los casos en que el dominio no puede
inferirse desde el modelo. Y por ejemplo con atributos, a mi no me
parece del todo invasivo.

Desde mi punto de vista lograron poner patas para arriba el problema,
es decir, en vez de buscar donde poner la metada? (que es algo
practicamente sin sentido)
yo pensaría
1-cual era el problema?
2-Que información estaría faltando para poder generar lo que queremos?
3-se puede resolver agregando metadata a las clases del modelo?
4-esta metadata sería de alguna manera invasiva descripta como
atributos, estaría mejor separada /etc..?

Ojo, tratar de resolver 4 sin tener en claro las primeras 3 no es una
alternativa. Y lo digo por que empezamos a hablar de "metadata de ui"
y metadata de aquello..

On 23 mar, 12:09, Daniel Calvin <daniel.cal...@gmail.com> wrote:
> Diego,
>
> Seguro no es fácil, pero ...
>
> El 23 de marzo de 2009 12:02, Diego Jancic <jan...@gmail.com> escribió:
>
>
>
> > Cuando tenes razon, tenes razon...
> > Lo unico que decia es de no poner la metadata en el dominio, al menos
> > no TODA la metadata... donde deberia ir es otra cuestion..
>
> > > 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...
>
> > Puede funcionar, el tema es que pasa cuando la misma metadata se usa
> > en multiples niveles?  Por ejemplo el largo maximo de un campo, lo
> > usas en la UI para validar, lo usas en la base de datos, lo usas en
> > algun servicio seguramente para validar, y seguramente muchos otros
> > lugares..
>
> > Entonces no se si el criterio de dividir es tan claro, aunque creo que
> > si se define un buen criterio puede funcionar...
>

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

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

> > >> > El 22 de marzo de 2009 22:47, Claudio Meschini <cmesch...@gmail.com>

> > >> >> <conta...@darioquintana.com.ar> escribió:

> > >> >>> 2009/3/22 Claudio Meschini <cmesch...@gmail.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,
>

> ...
>
> leer más »

[Diego Jancic]

> NHV te recuerda algo ?

Si... podria ser.. pero te respondo con palabras de Daniel Calvin: "O,

según tu planteo, no la meto en e dominio pero la meto en un
repositorio comun a toda la metadata. otro uhmmm..."

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

[Daniel Calvin]

Hola Jose

Creo que no lo dimos vuelta, yo me referia a que determinadas cosas no son invasivas.
Si otras lo son no las pondría como adornos en las clases del dominio.

1-cual era el problema? Creo que estaba claro
2-Que información estaría faltando para poder generar lo que queremos? Fundamentalemente inf. de ciclo de vida, seguramente algo mas, yo opine sobre ese particular.
3-se puede resolver agregando metadata a las clases del modelo? Una parte si, ver ( 2 )

4-esta metadata sería de alguna manera invasiva descripta como

atributos, estaría mejor separada /etc..? Una parte creo que podrían ser atributos, otra cuetiones, no.

Tal vez si la idea es que todo se exprese como metadata no tenga sentido que una parte este en un lugar y otra no. ( todo junto no me gusta )

Daniel

[JoseFR]

Bien creo que coincido con vos desde un principio.

sin hilar muy fino en que afecta el ciclo de vida al fw a desarrollar?
A->B
Factura->LineaFactura
Grupo->Persona

1-¿Es posible o tiene sentido persistir una instancia de B que no
pertenezca a ningun A? Agregado: Si, Composite: No
2-¿Es posible la existencia de B sin A? Agregado: Si, Composite: No
3-¿Sería factible eliminar en cascada instancias de B, al eliminar la
instancia de A? Agregado: Si, Composite: No

Por el momento no se me ocurre otra pero estoy poco inspirado.
Simplificando mas la cosa... todas me llevan en una sola dirección
B.A / LineaFactura.Factura / Persona.Grupo ¿acepta nulo?
Si no acepta nulos, estariamos en presencia de una persona que no
puede existir sin su grupo, una linea de factura que no puede existir
sin su factura..etc
(eliminar en cascadas / nullifies / set default / etc otros temas a
resolver)

Para indicar esto directamente en el modelo se me ocurren 3 formas:
1-Agregar un atributo [Composite] o [Aggregate] en
Factura.LineasFactura
2-Agregar un atributo [NotNull] en LineaFactura.Factura (puede ser el
de NHV)
3-Esta no se si es posible, pero Persona.Grupo podría ser del tipo ?
Grupo es decir un nullable<Grupo>.

On 23 mar, 12:48, Daniel Calvin <daniel.cal...@gmail.com> wrote:
> Hola Jose
>
> Creo que no lo dimos vuelta, yo me referia a que determinadas cosas no son
> invasivas.
> Si otras lo son no las pondría como adornos en las clases del dominio.
>
> 1-cual era el problema? Creo que estaba claro
> 2-Que información estaría faltando para poder generar lo que queremos?
> Fundamentalemente inf. de ciclo de vida, seguramente algo mas, yo opine
> sobre ese particular.
> 3-se puede resolver agregando metadata a las clases del modelo? Una parte
> si, ver ( 2 )
> 4-esta metadata sería de alguna manera invasiva descripta como
> atributos, estaría mejor separada /etc..? Una parte creo que podrían ser
> atributos, otra cuetiones, no.
>
> Tal vez si la idea es que todo se exprese como metadata no tenga sentido que
> una parte este en un lugar y otra no. ( todo junto no me gusta )
>
> Daniel
>

> ...
>
> leer más »

[Daniel Calvin]

Yo trataria de simplificarlo aun mas, en UML vos podes decir, sea composición o agregación,

0..1 o 1..* o cosas por el estilo.
Eso no solo define el ciclo, A o C, tambien el null o navegación inversa y hasta limite en la multiplicidad.

Usar un esquema asi permite usar la rueda ya inventada...

Daniel

[JoseFR]

Otras ideas bien objected-oriented podría ser no borrar líneas de
factura al eliminar una factura...

**Eliminarla cuando no existan referencias hacia ese objeto ?
**Que exista un servicio "garbage collector de instancias
persistentes" al igual que el gc de memoria


(ambas ideas requieren muuuucho trabajo)

> ...
>
> leer más »

[Fabio Maulo]

El 23 de marzo de 2009 13:35, JoseFR <jfroma...@gmail.com> escribió:

(ambas ideas requieren muuuucho trabajo)

Es lo que nos pasa en open-source.

I prefer to try something good and fail, than to try something wrong and achieve it.

--
Fabio Maulo

[JoseFR]

Entre 1 y *: no hay dudas.
Por ejemplo si las facturas pueden tener 1 sola línea; en la clase
Factura la propiedad sería Linea (singular) y del tipo LineaFactura
Si la fas facturas pueden tener N lineas.. la propiedad sería Lineas
(plural) y del tipo IEnumerable<LineaFactura>

Por otro lado no se en que parte/diagrama de UML podes definir la
multiplicidad de la manera que describis, me parece que definir la
multiplicidad de esa forma 0..1 y 1..* es mas DER (relacional).

On 23 mar, 13:31, Daniel Calvin <daniel.cal...@gmail.com> wrote:
> Yo trataria de simplificarlo aun mas, en UML vos podes decir, sea
> composición o agregación,
>
> 0..1 o 1..* o cosas por el estilo.
> Eso no solo define el ciclo, A o C, tambien el null o navegación inversa y
> hasta limite en la multiplicidad.
>
> Usar un esquema asi permite usar la rueda ya inventada...
>
> Daniel
>

> ...
>
> leer más »

[JoseFR]

Esta buena tu frase (espero que no sea una manera cordial de decir "te
mandaste cualquiera")
acabo de poner "garbage collector"+"oodbms" en google y algo hay,
al menos no fui el primero


On 23 mar, 13:40, Fabio Maulo <fabioma...@gmail.com> wrote:

[JoseFR]

cito aca lo ultimo sobre el garbage collector:

An ODBMS with Garbage Collection
based object removal completely eliminates this
problem. Persistent objects are only “deleted” once they
are no longer referenced by any other instances
reachable from a well-defined root object. (...)

Referencia:
http://www.odbms.org/download/021.01%20Coetzee%20Experiences%20using%20an%20ODBMS%20for%20a%20High-Volume%20Internet%20Banking%20System%20October%202003.PDF

[Fabio Maulo]

El 23 de marzo de 2009 14:11, JoseFR <jfroma...@gmail.com> escribió:

Esta buena tu frase (espero que no sea una manera cordial de decir "te
mandaste cualquiera")

No, es una manera de decir algo que vengo diciendo hace mucho.

Para las cosas "simple" y a veces aburridas tenemos el trabajo de todos los dias (allí es donde vamos buscando pequeños desafio para no aburrirnos demasiado)

Por lo general los que nos pasa a quien hemos trabajado en framework es que pensar, diseñar e implementar el FW no es nada facil "In general a framework is to make something easy to the framework users and not to the framework developers."

--
Fabio Maulo

[Fabio Maulo]

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

cito aca lo ultimo sobre el garbage collector:

 An ODBMS with Garbage Collection
based object removal completely eliminates this
problem. Persistent objects are only “deleted” once they
are no longer referenced by any other instances
reachable from a well-defined root object. (...)

Si, es en parte (muy en parte) lo que hace NH con delete-orphan

--
Fabio Maulo

[Daniel Calvin]

>>Por otro lado no se en que parte/diagrama de UML podes definir la
multiplicidad de la manera que describis, me parece que definir la
multiplicidad de esa forma 0..1 y 1..* es mas DER (relacional).

El diagrama/parte es el diagrama clases.
Son adornos sobre las asociaciones, ( del tipo que sean ), pueden incluir el nombre del extremo ( eso sería la propiedad con la que se implementa la asociacion ) y su multiplicidad, ademas hasta podrías indicar el tipo con el que se implementa la propiedad, eso se ve como un rectangulito saliendo de la clase.

Lo que escribi no es un DER es UML, la idea justamente era no inventar nada, puse el ejemplo de una sintaxis existente y que se utiliza para generar codigo si se quiere.

Podes tener un ejemplo rapido aca:

http://en.wikipedia.org/wiki/Class_diagram

Daniel

[JoseFR]

Si! tenes razón yo me equivoque, el diagrama de clases puede incluir
multiplicidad tal cual lo describis.
De todas formas insisto que el hecho de que el extremo sea 1 o n,
puede ser inferido a partir del Tipo de la propiedad, de esta manera
no hay que agregar ningun atributo ni crear ninguna metadata extra (no
así para una multiplicidad abitraria, por decir la factura acepta 3
lineas)

Sobre el otro extremo 0 o 1 (nulo o no), bueno mantengo mi opinión
sobre las tres alternativas que di antes.

On 23 mar, 14:35, Daniel Calvin <daniel.cal...@gmail.com> wrote:
> >>Por otro lado no se en que parte/diagrama de UML podes definir la
>
> multiplicidad de la manera que describis, me parece que definir la
> multiplicidad de esa forma 0..1 y 1..* es mas DER (relacional).
>
> El diagrama/parte es el diagrama clases.
> Son adornos sobre las asociaciones, ( del tipo que sean ), pueden incluir el
> nombre del extremo ( eso sería la propiedad con la que se implementa la
> asociacion ) y su multiplicidad, ademas hasta podrías indicar el tipo con el
> que se implementa la propiedad, eso se ve como un rectangulito saliendo de
> la clase.
>
> Lo que escribi no es un DER es UML, la idea justamente era no inventar nada,
> puse el ejemplo de una sintaxis existente y que se utiliza para generar
> codigo si se quiere.
>
> Podes tener un ejemplo rapido aca:
>
> http://en.wikipedia.org/wiki/Class_diagram
>
> Daniel
>

[Daniel Calvin]

Jose

No digo poner atributos donde no sea necesario, solo explique la notación completa.

[Composite( )]

o

[Composite( 0, *)]

podrían ser equivalentes

Si la navegación es bidireccional del otro lado podrías tener:

[Composite( 1, 1)]

o

[Composite( 1)]


Daniel

[Daniel Cazzulino]

Como para pensar fuera de los estandares de RDBMS, me preocupa como escala cualquier store en precencia de sharding, y evoluciones de esquema "live".

Un interesante articulo al respecto: http://bret.appspot.com/entry/how-friendfeed-uses-mysql

Quizas hay q ser mucho mas drasticos?? ;)

/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471

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

[JoseFR]

En una presentación de Sql server que hicieron aca en Córdoba el
presentador "imagino" alguna situación donde todas las entidades se
guardaran en la misma tabla en un campo xml, y luego poder accederlas
a traves de XQuery.

En mi humilde opinión, si bien me parece que podría ser una
posibilidad creo que sería un desperdicio usar un RDBMS de esa manera.

On 23 mar, 15:40, Daniel Cazzulino <kzu....@gmail.com> wrote:
> Como para pensar fuera de los estandares de RDBMS, me preocupa como escala
> cualquier store en precencia de sharding, y evoluciones de esquema "live".
>
> Un interesante articulo al respecto:http://bret.appspot.com/entry/how-friendfeed-uses-mysql
>
> Quizas hay q ser mucho mas drasticos?? ;)
>
> /kzu
>
> --
> Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1
> 425.329.3471
>

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

>
> > Jose
>
> > No digo poner atributos donde no sea necesario, solo explique la notación
> > completa.
>
> > [Composite( )]
>
> > o
>
> > [Composite( 0, *)]
>
> > podrían ser equivalentes
>
> > Si la navegación es bidireccional del otro lado podrías tener:
>
> > [Composite( 1, 1)]
>
> > o
>
> > [Composite( 1)]
>
> > Daniel
>

> ...
>
> leer más »

[Daniel Cazzulino]

Claro, el tema pasa mas por los problemas (inherentes?) de escalabilidad y flexibilidad con los enfoques tradicionales a DBs, creo...

/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471

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

[Martín Salías]

Es cierto que tenemos varios gurúes y mentes brillantes, pero no te preocupes que los gurúes no van a venir porque a esa hora están facturando, y las mentes brillantes por ahí vienen, pero se adhieren al techo y sólo bajan para la birra o si aparece alguna niña.   :)

En resumen, estos eventos son de mortales, para mortales. Lo único que puede pasar es que en algún tema te sientas "menos conocedor", pero no hay que preocuparse, que a todos les pasa, aunque muchos jamás lo admitan.  :D

Saludos,

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

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

[Fabian Figueredo]

Me parece que la broma que intentó hacer Fabio con su respuesta no fué
muy acertada en este contexto.

En cambio tu respuesta Martin me parece mucho más acertada. Algunos
pueden ser más inteligentes que otros, pero un verdadero gurú es sobre
todo humilde y comparte sus conocimientos.

Creo que si habrán gurúes y mentes brillantes en la reunión y también
habrán muchas personas que quieren aprender.
Si en cambio, el motivo de estas reuniones es otra, a mi no me
interesaría asistir.

Saludos.
Fabián Figueredo

[Carlos Peix]

Hola Fabian,

Solo quisiera agregar una palabra a favor de Fabio como persona.

Es realmente humilde, ya lo conoceras, solo que a veces usa mal el teclado :).

Te pido que no lo juzgues por ese post y le des al tano una nueva oportunidad.

Un abrazo

Carlos Peix

2009/3/24 Fabian Figueredo <fabianf...@gmail.com>:

[Fabian Figueredo]

Nahh ;) A quien voy a juzgar yo?

Ya lo sé, fué una broma de Fabio. Y lo del teclado, yo también soy así.
Simplemente me chocó un poco su respuesta, pero no más que eso. Espero
no haberlo ofendido, te aseguro que no fué mi intención.

Saludos.
Fabián Figueredo

[JoseFR]

Quería acotar algo, yo que soy quien hizo la pregunta y recibio la
respuesta no me senti para nada ofendido ni nada, ni me molesto la
respuesta.
Hay que decir la verdad y yo la entiendo desde antes de hacer la
pregunta, alguien que te este frenando todo el tiempo con preguntas
sonsas como :

"Che vos... podes parar de hablar y explicarme que significa
STATIC?" (Y ojo que aunque parezca que no se da es la razón por la
cual no voy mas a casi ninguna presentación de producto ms - MENOS
GRATIS)

es totalmente antiproducende.

yo quería acotar un chiste, no me lo podía guardar:

"Fabio, osea que si llevo el diploma de programador 3 estrellas por
ahi puedo pasar?"

On 24 mar, 08:17, Fabian Figueredo <fabianfiguer...@gmail.com> wrote:
> Nahh ;) A quien voy a juzgar yo?
>
> Ya lo sé, fué una broma de Fabio. Y lo del teclado, yo también soy así.
> Simplemente me chocó un poco su respuesta, pero no más que eso. Espero
> no haberlo ofendido, te aseguro que no fué mi intención.
>
> Saludos.
> Fabián Figueredo
>

> El día 24 de marzo de 2009 8:02, Carlos Peix <carlos.p...@gmail.com> escribió:
>
>
>
> > Hola Fabian,
>
> > Solo quisiera agregar una palabra a favor de Fabio como persona.
>
> > Es realmente humilde, ya lo conoceras, solo que a veces usa mal el teclado :).
>
> > Te pido que no lo juzgues por ese post y le des al tano una nueva oportunidad.
>
> > Un abrazo
>
> > Carlos Peix
>

> > 2009/3/24 Fabian Figueredo <fabianfiguer...@gmail.com>:

>
> >> Me parece que la broma que intentó hacer Fabio con su respuesta no fué
> >> muy acertada en este contexto.
>
> >> En cambio tu respuesta Martin me parece mucho más acertada. Algunos
> >> pueden ser más inteligentes que otros, pero un verdadero gurú es sobre
> >> todo humilde y comparte sus conocimientos.
>
> >> Creo que si habrán gurúes y mentes brillantes en la reunión y también
> >> habrán muchas personas que quieren aprender.
> >> Si en cambio, el motivo de estas reuniones es otra, a mi no me
> >> interesaría asistir.
>
> >> Saludos.
> >> Fabián Figueredo
>
> >> El día 24 de marzo de 2009 0:32, Martín Salías <mar...@salias.com.ar> escribió:
> >>> Es cierto que tenemos varios gurúes y mentes brillantes, pero no te
> >>> preocupes que los gurúes no van a venir porque a esa hora están facturando,
> >>> y las mentes brillantes por ahí vienen, pero se adhieren al techo y sólo
> >>> bajan para la birra o si aparece alguna niña.   :)
> >>> En resumen, estos eventos son de mortales, para mortales. Lo único que puede
> >>> pasar es que en algún tema te sientas "menos conocedor", pero no hay que
> >>> preocuparse, que a todos les pasa, aunque muchos jamás lo admitan.  :D
> >>> Saludos,
> >>> ---
> >>> Martín Salías
> >>>http://blog.Salias.com.ar
>

> >>> 2009/3/23 Fabio Maulo <fabioma...@gmail.com>

[Fabio Maulo]

El 24 de marzo de 2009 21:57, JoseFR <jfroma...@gmail.com> escribió:

"Fabio, osea que si llevo el diploma de programador 3 estrellas por
ahi puedo pasar?"

Disculpen, la pregunta es personal.

 

Como habras visto en esta lista, y por lo general es normal en Alt.Net, hay muchos de lo que en la comunidad de desarrolladores se consideran comunmente Maestros. Por lo general ninguno de los que los desarrolladores llamamos Mestros se consideran a si mismo un Maestro.

En mi carrera professional (a hoy mas de 23 años) he conocido chicos que aún tenia que terminar el secundario y hasta algunos que nunca lo terminaron y, sinembargo, erán y son mentes brillantes, logran ver cosas, en IT, que algún otro con titulo de igeniero no logran ver (mucho solo porque no quieren ver).

En IT, y probabelmente en otros campos, el titulo es solo el inicio; no te alcanza para toda tu vida professional.

En IT no se puede parar, siempre hay que seguir estudiando; probablemente, lo que consideramos Maestros, son además lo que mas passión tienen hacia IT.

Justo hoy hablaba con una persona, que empezó siendo un colega y terminó siendo un amigo, buscando la forma de explicarle que es Alt.Net; a pesar de como Alt.Net empezó lo lindo del movimiento son exactamente las reuniones y las charlas open-space.

En Alt.Net veo la gran posibilidad de participar y compartir ideas con aquellos que siguen haciendo el futuro de IT.

Para participar, IMO, alcanza con tener abertura mental.

En IT la actitud de un chico de 5 años muchas veces es la que gana, siempre queda mucho para aprender.

Bye.

Fabio Maulo

[JoseFR]

Bueno gracias por contestar, yo si bien me empece a interesar de muy
chico por esta profesión y hoy en día vivo de esto aun me considero
MUY nuevo, sobre todo a estas practicas/reuniones se refiere (mi edad
es equivalente a tus años de profesión).

Tener un espacio donde poder debatir y expresar el tipo de ideas como
el que hace mención el titulo de este hilo y que esto lleve a una
reunión donde se pueda discutir me parece algo extraordinario y
totalmente interesante.

Lo de desarrollador 3 estrellas fue solo un chiste.


On 25 mar, 00:37, Fabio Maulo <fabioma...@gmail.com> wrote:

[Martín Salías]

Hola, José.

Entiendo tu cautela, pero te digo lo mismo que a mucha gente que me comenta por ejemplo que no pregunta algunas cosas en una lista porque le parece que son muy elementales:

Si no preguntás y no tratás de entender lo que "te queda grande", nunca aprendés, o lo hacés solamente "a demanda" para cubrir exactamente lo que la tarea a mano te requiere. El espíritu de ALT.NET es el de meterse en temas aunque no los domines y tratar de sacar temas en claro.

Todos somos principiantes en algún punto. El Tano y yo somos viejos y gruñones, pero te aseguro que aprendemos cosas TODOS los días, muchas veces de pibes que podrían ser nuestros hijos. :)

Es como en el colegio: si no te enseñaran derivadas (que la mayoría no llegamos a usar el resto de nuestra vida) dificilmente te quedarían bien grabados conceptos más básicos. Siempre tenés que tirarte más arriba, y a veces parte de eso es quedarse con dudas (¿qué sería eso de "interfaz fluida" de que tanto hablaban?). La buena noticia es que hoy estás a un Search de encontrar respuestas, y después tenés estos grupos para profundizar y descubrir cómo y cuándo la gente usa cada cosa.

Un abrazo y esperamos verte en el Open Space!

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

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

[JoseFR]

Gracias Matías! me gustaría mucho ir, voy a tratar de viajar (soy de
Córdoba).

On 25 mar, 23:21, Martín Salías <mar...@salias.com.ar> wrote:
> Hola, José.
> Entiendo tu cautela, pero te digo lo mismo que a mucha gente que me comenta
> por ejemplo que no pregunta algunas cosas en una lista porque le parece que
> son muy elementales:
>
> Si no preguntás y no tratás de entender lo que "te queda grande", nunca
> aprendés, o lo hacés solamente "a demanda" para cubrir exactamente lo que la
> tarea a mano te requiere. El espíritu de ALT.NET es el de meterse en temas
> aunque no los domines y tratar de sacar temas en claro.
>
> Todos somos principiantes en algún punto. El Tano y yo somos viejos y
> gruñones, pero te aseguro que aprendemos cosas TODOS los días, muchas veces
> de pibes que podrían ser nuestros hijos. :)
>
> Es como en el colegio: si no te enseñaran derivadas (que la mayoría no
> llegamos a usar el resto de nuestra vida) dificilmente te quedarían bien
> grabados conceptos más básicos. Siempre tenés que tirarte más arriba, y a
> veces parte de eso es quedarse con dudas (¿qué sería eso de "interfaz
> fluida" de que tanto hablaban?). La buena noticia es que hoy estás a un
> Search de encontrar respuestas, y después tenés estos grupos para
> profundizar y descubrir cómo y cuándo la gente usa cada cosa.
>
> Un abrazo y esperamos verte en el Open Space!
>
> ---
> Martín Salíashttp://blog.Salias.com.ar
>

> 2009/3/25 JoseFR <jfromanie...@gmail.com>

[Eugenio Serrano]

Hola Jose...

A mi tambien me gustaria ir... Sino, mas adelante podriamos replicar
algun evento en Cordoba, no ?
:)

Saludos,
Eugenio

--
Saludos,
Eugenio Serrano
Microsoft MVP / ASP.Net
Solid Quality Mentors

["José F. Romaniello"]

seeeeeeeeeeeee sr!
Yo pongo un voto para que vos des el discurso inicial.
Estaba viendo y merd.. como pasan los años creo que la ultima vez que fui a una conferencia que diste vos fue esta: http://www.mug.org.ar/Eventos/1722.aspx . Yo estaba en la 3ra fila y te hice 18 preguntas, (el pesado de la mañana).
Ahí me regalaron el DVD de Visual Studio 2005 y Sql 2005 con licencias standard y cuya caja parecía la de un concierto de los rolling stones.


Eugenio Serrano escribió:

[Jorge Gamba]

Este tema está muy bueno, a mi también me ocupa la mente desde hace
tiempo. Pero, en mi humilde opinión, me parece que ha ido apartando de
la cuestión incial

> 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();

"Cuál es el proceso mental que lleva a elegir ..."

Pienso que por ahora hay que abordar el asunto más por el lado de
diseño conceptual, que de implementación, eso vendrá después de que se
definan los detalles de lo primero, pues el diseño determina la
implementación.

Me uno al comentario de que hay que pensarlo para los usuarios no para
los desarrolladores. Entonces, hay que abstraer cómo lo hacen los
usarios, las personas en el mundo real. Para seguir con el ejemplo de
factura, digamos que se contrata como vendedor/cajero de una
ferretería a alguien que ignora totalmente como es ese negocio, sin
conocimiento de contabilidad o economía (no ha visto ni diligenciado
la primera factura en su vida) y se le pide que diligencie manualmente
facturas a los clientes, por más que le den montones de reglas
aplicables al diligenciamiento de formularios en general, respecto al
número, posición, cómo escribir en los campos; él no va a poder
"inferir" cómo diligenciar el formato factura acertadamente, le haría
falta el conocimiento específico de "ese negocio" para por ejemplo
mantener la relación entre cantidad, valor unitario, total, gran
total, no se trata de solo matemáticas sino de reglas del negocio y
validaciones muy específicas de ese tipo de formato y no de otros.

Aplicando esa analogía a "la persistencia acertada", sin mapeo, no
creo que la "inferencia" total sea el mejor método, pues siempre se
puede escapar algo que no se previó, obtener un resultado no deseado,
la persistencia impondría un montón de cosas al dominio de la
aplicación y es imposible preveer todas las variedades de negocios que
podrían usarla. Creo que estaremos de acuerdo que es mejor si el
objeto, componente o agregado que vamos a persistir ignora en lo
posible quién y haciendo qué, se le va a persistir, al mismo tiempo
que si sabe y determina de qué manera se debe hacer, pues es el
dominio/negocio quien mejor lo sabe. Los recursos empleados para la
persistencia solo deberían ser vistos como eso, "recursos del dominio
de la aplicación" (ORM, frameworks, Repositorio, RDBMS, DB...) a los
cuales puede recurrir para lograr parte de su cometido (la
persistencia/almacenamiento) y él uno no debería decirle al otro
(dominio vs. persistencia) cómo hacer su trabajo (desacoplamiento)
pero sí qué espera de él.

Propuesta:
la estrategia que me parece tendría dos componentes:
1. Definir un "estándar para la descripción del dominio", con todo y
sus partes (obetos, componentes, agregados) que se materialice bien
sea en xml, atributos, interfaz fluida, usando un diseñador visual,
generador de cógido, herramienta de modelado o lo que sea, al mismo
tiempo debería poder permitir definir preferencias sobre por ejemplo
el método para vencer la impedance mismatch, algunas reglas, tal vez
comportamiento, como dije antes la implementación se podría ver
después.
2. Un "motor" que estaría dentro de "quien" administre la
persistencia, que reconozca, interprete el dominio y tenga en cuenta
algunas reglas definidas desde el dominio.

Para acerme entender mejor lo ilustro y aplico a NHibernate (debería
ser lo más estándar y universal posible), uno elabora un hbm o coloca
atributos, de esa manera le entrega metadata del mapping y NH sabrá
como hace su trabajo. En el caso de la "propuesta", en vez de
entregarle el mapping, le entregaría la "descripción" del dominio (es
raíz, es o usa composición/agregación, colecciones, es editable, solo
lectura, estructura de árblo, prefiera tabla por clase, etc.), NH lo
interpretaría y haría su trabajo.

Yo se que no suena tan "manos libres" como es el deseo inicial, sino
más bien suena como "otra forma de informarle a NHibernate como
persistir", pero cumple parte de los objetivos y de paso ayuda a
organizar mejor el dominio (inicialmente solo pensando en su
persistencia pero podría ser principio de algo más útil y completo).

Perdón por la extensión de este mail, pero son muchas las ideas que se
pueden postear (com para un blog). Me gustaría estar junto a algunos
de ustedes en el tablero blanco pero hay mucha tierra en medio
(Colombia->Argentina), tal vez si prospera la idea de Diego Jancic de
"Virtual Altnet-Hispano"...

P.S. Péguense la pasadita por http://groups.google.com/group/altnet-hispano,
hay una descripción completa en español de ALT.NET

[Jorge Gamba]

["José F. Romaniello"]

Después de pensarlo un tiempo, ahí va mi mejor intento.

¿Cual es la diferencia entre modelo y dominio? Estas dos palabras que usamos normalmente y a veces de la misma manera.
Me pareció bueno citar este artículo de Eric Evans:
 http://domaindrivendesign.org/discussion/blog/evans_eric_ddd_and_mdd.html

Del que voy a sacar este párrafo:

    "That distillation of knowledge into a clear set of concepts is a modeling process. Those models live in the language of the team, and every conversation in that language can be a modeling session. And so domain-driven design leads inevitably to modeling because modeling is the way we grapple with understanding complex domains."

Esta claro que nosotros creamos un "modelo" a partir de lo que entendemos acerca del "dominio" del problema. El core de ese modelo podrían ser nuestros clases por el momento simples, solo lo que los frameworks actuales nos dejan definir. A lo que me refería en uno de los primeros mails es que al definir una relación en la forma de "one-to-many", una relación inversa o un componente estamos en cierta forma:

    "Mejorando o completando el modelo para que represente mas hechos o factores del dominio" y eso esta perfecto, solo que la forma de hacerlo es a través de conceptos relacionales heredados de una limitación pero muy arraigados.

    Lo importante para mi no sería cambiarle el nombre a las cosas para que suenen mas bonitas sino poder mejorar la definición del modelo de manera que nos podamos acercar mas al dominio sin utilizar conceptos ni tecnología relacional, sin ningún "ruido" y de la forma mas natural posible.

    En caso contrario de intentar hacer que los clases definidas como actualmente las definimos, se puedan guardar de forma cruda estaríamos frente a una especie de LinqToSQL , con la única variante que genera la bd a partir de las clases (LinqToSql hace lo inverso) y creo que esto no agrega mucho. De hecho LinqToSQL no funciona bien para crear un modelo de dominio sino para crear una capa de acceso a datos (como referencia se puede ver primeros los 10 primeros capitulos de Rob Connery creando el StoreFront).

    Una de las frases mas comentadas en este hilo dice lo siguiente:

	Che.Tengo("MiDominio.dll").Que.TieneQuePersistirEn("ORACLE").FijateVos();

    De forma casual o causal dice "MiDominio.dll" bien podría decir "MiModeloDeDominioBasadaEnSimplesObjetos.dll".

    De ahí fue que comenzamos a hablar de agregar detalles en forma de atributos, metadatas, etc.

Bueno, espero sus opiniones!

Jorge Gamba escribió:

[JoseFR]

ups, se me chiflo por contestar desde el thunderbird.

[Jorge Gamba]

y a mi desde Firefox

[Fabio Maulo]

La solución nunca es una sola.

Si fuese una hiriamos hacias DSL y generación de todo lo que se pueda generar o definir las classes en C# y definir el mapeo de persistencia de alguna forma.

El life-motive inicial de ORuM era : Mapping by difference

Traducido sería: no uses el mapping para decirme lo que ya se.

De allí viene el tema de: que es lo que sabes ? cuanta "cosas" se que conciernen la persistencia se pueden inferir mirando una clase ? Cuantas cosas se pueden inferir mirando un dominio de classes y un schema de DB ? cuanto se puede establecer por convención de una determinada applicacción ?

La primera vez que puse la palabra ORuM fuera de una charla con amigos fue acá

http://groups.google.com.ar/group/fluent-nhibernate/browse_thread/thread/44f7176442aa0d85

La metadata :

Es posible que hayan varias "cosas" que, por ahora, no encotramos la forma de inferirlas. Me gustaría que haya un sistema tan intelligente que me diga lo que no comprende que me pregunte  y, en lo posible, aprenda; también queda siempre el caso de "esto lo haces como digo yo y punto". Donde el sistema se meta la "meta-data" me interesa muy poco, lo importante es que no me haga dos veces la misma pregunta. 

Mi padre dice que, aunque el trabajo hace mas noble el hombre tambien lo hace similar a la bestia. Las maquinas no tienes familia, no tienen que pagar impuestos, no tienen preocupaciones etc... podríamos hacer que trabajen un poco mas de lo que hacen ahora, no?

P.S. a la ultima pregunta me contesto solo con una frase de Angel : "viste la luz!" ;)

--
Fabio Maulo

[Gustavo Ringel]

Yo probablemente estoy muy lejos de entender directamente el concepto sobre la Inteligencia Artificial, etc.

Pero basicamente si ahora agarro en mi mesa una taza un telefono y un CD y los tengo que armar de menor a mayor, o mirando la biblioteca decidir si tengo espacio o no para meter un libro...por mas que tengo familia, preocupaciones y demas, soy mucho mas habil (y a mi gusto tambien lo sere) que una computadora.

Inferir cosas basicas esta barbaro, pero automatizar todo porque la "computadora no se cansa" no se, no estoy de acuerdo, para todo esta el factor humano.

Hace poco con un sistema que estamos proponiendo se pusieron a discutir si el cliente recibe un aparato arreglado directo de una maquina o desde una persona en el mostrador. Si bien esto ultimo es mas lento, y genera un poco mas de problema, a lo largo del tiempo la empresa de telefonica vio que telefonos que se devuelve con explicacion humana, regresan al taller con mucho menos frecuencia que los que se enviaron por Delivery sin explicacion de un humano (solo papel de descripcion)

Leer un blog no enseña como ir a un Open Source y sentarse hablar, ORuM no tomara decisiones como las que pueda tomar un grupo de trabajo...

Bueno, yo estoy de acuerdo en que se puede tratar de generar ya sea codigo dinamico o estatico...pero no se, algo no me gusta en todo el discurso hasta ahora, ni en ningun forum previo donde se hable de generacion para el que me sigue. Quizas tengo que esperar para ver la luz.

Saludos.

Gustavo.

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

[Gustavo Ringel]

Open Source = Open Space y el tono salio asi calculo que porque hoy adelantaron la hora y nadie le explico al reloj biologico de mis hijos...pero bueno, alguna vez voy a pasar a Buenos Aires, y Malbec mediante (el cual no disfrutan las computadoras tampoco) discutimos el tema :)

Abrazo.

Gustavo.

2009/3/27 Gustavo Ringel <gustavo...@gmail.com>