Programación con un gestor de base de datos orientado a objetos

tienes que leer respecto de lo que son las dependencias funcionales, ya que esa es la base del modelo relacional.

una vez entendido eso, el resto se trata de: ¿en qué contextos se puede aplicar las dependencias funcionales?

pues bien, hasta el momento, desde mi punto de vista, en todos. desde la generación de interfaces de usuario a la especificiación de requerimientos, pasando por el modelamiento de bases de datos.

saludos,

Guillermo.

2011/1/16 gerard <[hidden email]>

No he entendido nada :|

Bueno, el primer párrafo si ;))

Saludos

On 16 ene, 15:00, Guillermo Schwarz <[hidden email]>
wrote:

> Me parece muy superficial la discusiòn.
>
> De partida el modelamiento de base de datos relacionales parte de la idea E.
> F. Codd (http://www.dcc.uchile.cl/~rbaeza/inf/codd.html) de modelar las
> dependencias funcionales (http://cs.gmu.edu/~aobaidi/spring-02/Normalization.ppt), que no son otra
> cosa que pares X -> Y (como un Dictionary o un HashMap). Eso se puede
> representar directamente en Smalltalk.
>
> La representación E-R y la representación en tablas son sólo el resultado de
> tratar de convertir las dependencias funcionales en una representación
> entendible por humanos y por máquinas respectivamente. Lo simpàtico del
> asunto es que las dependencias funcionales podrìan representarse
> directamente en Smalltalk sin necesidad de mecanismos intermedios, derivando
> luego el modelo E-R o el modelo en tablas según sea necesario.
>
> Podrìas tener aplicaciones funcionando, cambiar las dependencias
> funcionales, y que la aplicación se adapte a los cambios sin necesidad de
> reprogramar nada ni de detener la aplicación.
>
> Para los que tengan dificultades entendiendo lo anterior, serìa factible
> hacer un generador de còdigo que genere interfaces de usuario, modelo de
> datos y migrador de datos en forma automática, aunque claramente prefiero
> que la aplicación no se detenga y siga funcionando sin necesidad de
> programar nada.
>
> Saludos,
> Guillermo.
>

> 2011/1/13 Juan <[hidden email]>

>
>
>
>
>
>
>
> > Hola gente
>
> > Bueno aporto un poco, creo que gaboto dijo algo claro y clave.
> > Tenes que pensar el dominio para modelarlo sin restricciones , lo de
> > la base de datos ,yo y quizas todo el mundo ,no se, lo llamo programacion
> > orientada al modelo de datos. o sea en bases de datos relacionales
> > se programa , los progamas son orientados a la representacion de los datos.
> > Entonces cuando cambias algun tipo de dato o definicion el programa sufre
> > cambios
> > a veces muy grandes.
> > El mapeo es una solucion intermedia. o sea se programa en "objetos" o en
> > lenguajes objetosos, excepto claro esta el smalltalk. y se mapea los
> > "objetos" a la db , teniendo
> > mas o menos exito.
> > En gral cuando se parte de esta formacion se tiende a mapear, una clase una
> > tabla una instancia una row.
> > Ese es el modelo de pensamiento que hay que romper, hay que pensar tu
> > objeto tu parte del modelo que necesita conocer? , las facturas ? ,ok. son
> > muchas ? bueno conocera una coleccion , y cada factura que necesita conocer?
> > , (por conocer digamos ,normalmente lo tiene o lo usa) podes arrancar con un
> > modelo exploratorio , en verdad deberias. y experimentar con los
> > colaboradores ( cosas q conoce otros objetos del dominio) e ir moviendolos
> > agregando sacando etc, hasta que pueda cumplir con su cometido ( el modelo
> > funcione) .
> > Luego pensa en la persistencia, no al reves. lo ultimo. o sea que el modelo
> > ande primero
> > luego la persistencia , asi como tambien te indicaron aqui y por
> > necesidades de perfomance u otras haces las "chanchadas" o sea ensucias a tu
> > modelo.
> > por ensuciar digamos que es la parte donde la persistencia afecta a tu
> > modelo .
> > bueno acoto hasta aca.
> > saludos
> > mdc
>

> > 2011/1/13 Gastón Dall' Oglio <[hidden email]>

>
> >> > Buenas, ya que estamos yo también me meto jeje.
>
> >> Buenas. Yo creo que la lista esta para que todo el que tenga algo que
> >> aportar lo haga :)
>
> >> Ya que estamos con el tema base de objetos y de datos, les consulto si
> >> alguno sabe que orientación tienen las bases de datos que se encuadran bajo
> >> el enfoque nosql. ¿Están tratando de hacer algo orientado a objetos o algo
> >> totalmente novedoso?
>
> >>http://nosql-database.org/
>

> >> El 13 de enero de 2011 10:58, Gaboto <[hidden email]> escribió:

>
> >> Buenas, ya que estamos yo también me meto jeje.
> >>> Solo un comentario. Para hacer un buen modelo en la base de objetos lo
> >>> que quizá deberías hacer es pensar en que tenés un programa en memoria y que
> >>> nunca se apaga. Es decir, imaginate que vos tenes que hacer un programa que
> >>> no tiene que persistir nada porque la compu siempre está prendida, Entonces,
> >>> en ese caso como harías? yo tendría las colecciones que correspondan y
> >>> agregaría algún diccionario por eficiencia, etc.
> >>> La consistencia del modelo la tendría que manejar el modelo mismo,
> >>> asegurandose de poner y sacar las cosas de las colecciones cuando
> >>> corresponda. No hay ningún trigger mágico ni nada de eso, que viene de otro
> >>> paradigma.
> >>> Yo creo que la idea de una base de objetos es justamente esa, hacer lo
> >>> más transparente posible la persistencia, aunque en realidad haya algunas
> >>> sutiles diferencias en la práctica...
> >>> Luego con el tiempo, como ya mencionaron acá, te vas a ir dando cuenta de
> >>> si hay que hacer alguna "chanchada" o algo para ir optimizando los tiempos.
>

> >>> 2011/1/13 Gastón Dall' Oglio <[hidden email]>

>
> >>>>  Muchas gracias por sus comentarios!
>
> >>>> Sí, el become ya me parecía una mala idea por lo que he leído.
>
> >>>> Saludos.
>

> >>>> El 13 de enero de 2011 08:48, Esteban Lorenzano <[hidden email]>escribió:

>
> >>>> hola,
> >>>>> bueno, me meto en el thread :)
> >>>>> IMHO, el problema es que seguís pensando tu estructura de datos en
> >>>>> relacional, no en objetos (por eso lo pensás como una estructura de datos y
> >>>>> no como un grafo de objetos, je).
> >>>>> Yo la primer pregunta que me haría es "para qué quiero la colección de
> >>>>> todas las facturas? las necesito, o es solo que 'me parece' que tienen que
> >>>>> estar en una colección aparte (como si la colección fuera una tabla)"
> >>>>> realmente me parece que es una instancia muy nueva de tu aplicación
> >>>>> (por lo que veo) para saber si realmente necesitas tener una colección de
> >>>>> facturas aparte. En estos momentos no hay nada que te impida hacer algo
> >>>>> como:
>
> >>>>> allInvoices
> >>>>>        ^self customers
> >>>>>                inject: Set new
> >>>>>                into: [ :all :each | all, each invoices ]
>
> >>>>> eso puede demostrarse no eficiente con el tiempo, pero también puede
> >>>>> demostrarse que no necesitás #allInvoices y entonces te ahorrás todo el
> >>>>> problema de mantener invoices en dos lugares.
> >>>>> Si pese a todo decidís que sí necesitas mantenerlo aparte, lo que te
> >>>>> recomiendo es lo mismo que te recomendó Andrés, y le agrego que, para borrar
> >>>>> facturas, hagas algo como:
>
> >>>>> Customer>>removeInvoice: anInvoice
> >>>>>        self invoices remove: anInvoice.
> >>>>>        IndexadorDeFacturas instance remove: anInvoice.
>
> >>>>> usar el become (forward o no), suele no ser una respuesta correcta.
> >>>>> Entre otras cosas porque te hace un scan de todos los objetos en memoria, en
> >>>>> pharo/squeak, dado que no tienen object table.
>
> >>>>> nunca dejes de pensar desde el punto de vista del modelo, olvidate de
> >>>>> pensar en la estructura!
>
> >>>>> Saludos,
> >>>>> Esteban
>
> >>>>> El 13/01/2011, a las 7:42a.m., andres escribió:
>
> >>>>> > Yo personalmente evitaría eso porque:
>
> >>>>> > 1. Estás asumiendo cosas sobre las colecciones que contienen a la
> >>>>> factura. Si el día de mañana se te ocurre cambiar el tipo de colecciones y
> >>>>> esas colecciones por algún motivo no pueden contener nils las rompés.
> >>>>> > 2. Tenés que redefinir el protocolo de colecciones para manejar tus
> >>>>> casos ad-hoc (ej. si tenés un array el #size ya no te sirve; tenés que hacer
> >>>>> (select:[..| noNil]) size).
> >>>>> > 3. Estás asumiendo que nadie mas referencia a la factura (ej. un
> >>>>> inspector, un reporte, un histórico de facturas, etc). Si así fuera rompés
> >>>>> todo.
> >>>>> > 4. Como regla genérica el #become no se debe usar para resolver
> >>>>> problemas de diseño; eso te lleva a una seguidilla de hackasos. Mejor es
> >>>>> definir alguien que sepa sincronizar bien las colecciones de facturas. Por
> >>>>> ejemplo, podés definir que el indexador global de facturas no puede agregar
> >>>>> o eliminar facturas, sólo el cliente lo hace. Entonces te queda:
>
> >>>>> > (private) IndexadorDeFacturas>>agregarFactura: unaFacura
> >>>>> >                                               self factuas add:
> >>>>> unaFactura.
>
> >>>>> > (public) Cliente>>agregarFactura: unaFacura
> >>>>> >                               self factuas add: unaFactura.
> >>>>> >                               IndexadorDeFacturas instance
> >>>>> agregarFactura: unaFacura.
>
> >>>>> > Si uno es lo suficientemente disciplinado como para no usar el
> >>>>> protocolo privado del indexador de facturas ya no hay problemas.
>
> >>>>> > IMHO es mucho menos esfuerzo hacer ese diseño que todo el quilombo
> >>>>> que te trae el become.
>
> >>>>> > HTH,
> >>>>> > Andrés
>
> >>>>> > Gastón Dall' Oglio escribió:
> >>>>> >> Hola gente.
> >>>>> >> Capaz es una burrada pero bueno, no me quiero quedar con las dudas.
> >>>>> >> Supongamos que tengo unaFactura que esta referenciada desde una
> >>>>> colección
> >>>>> >> perteneciente a un cliente (sus facturas) y también desde una
> >>>>> colección de
> >>>>> >> todas las facturas. Para el tema de resolver el "borrado en cascada"
> >>>>> puedo
> >>>>> >> hacer algo como:
> >>>>> >> unaFactura become: nil
> >>>>> >> 1) Esto me asegura que ya nadie la referencia, y será liberada.
> >>>>> >> 2) Ambas colecciones quedan con la misma cantidad de elementos, solo
> >>>>> que
> >>>>> >> ahora tienen una referencia a nil. Que exista una factura nil es
> >>>>> fácil de
> >>>>> >> ignorar con un #select: o permanente con un #removeAll:
> >>>>> >> 3) El tiempo normal que demora un #become: aumenta considerablemente
> >>>>> por
> >>>>> >> tratarse de objetos persistidos por Magma.
> >>>>> >> Saludos!
> >>>>> >> El 12 de enero de 2011 18:40, Hernán Morales Durand <

> >>>>> >> [hidden email]> escribió:
> >>>>> >>> Hola Gerard,
>
> >>>>> >>> El día 12 de enero de 2011 10:59, gerard <[hidden email]>

> >>>>> escribió:
> >>>>> >>>> Lo que hecho de menos es una "manera de hacer" estandar que
> >>>>> prevenga
>

> ...
>
> leer más »

--

To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

--
Saludos cordiales,

Guillermo Schwarz
Sun Certified Enterprise Architect

--

To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

Pienso totalmente lo contrario.
Saludos

2011/1/16 Guillermo Schwarz <[hidden email]>

tienes que leer respecto de lo que son las dependencias funcionales, ya que esa es la base del modelo relacional.

una vez entendido eso, el resto se trata de: ¿en qué contextos se puede aplicar las dependencias funcionales?

pues bien, hasta el momento, desde mi punto de vista, en todos. desde la generación de interfaces de usuario a la especificiación de requerimientos, pasando por el modelamiento de bases de datos.

saludos,

Guillermo.

2011/1/16 gerard <[hidden email]>

No he entendido nada :|

Bueno, el primer párrafo si ;))

Saludos

On 16 ene, 15:00, Guillermo Schwarz <[hidden email]>
wrote:

> Me parece muy superficial la discusiòn.
>
> De partida el modelamiento de base de datos relacionales parte de la idea E.
> F. Codd (http://www.dcc.uchile.cl/~rbaeza/inf/codd.html) de modelar las
> dependencias funcionales (http://cs.gmu.edu/~aobaidi/spring-02/Normalization.ppt), que no son otra
> cosa que pares X -> Y (como un Dictionary o un HashMap). Eso se puede
> representar directamente en Smalltalk.
>
> La representación E-R y la representación en tablas son sólo el resultado de
> tratar de convertir las dependencias funcionales en una representación
> entendible por humanos y por máquinas respectivamente. Lo simpàtico del
> asunto es que las dependencias funcionales podrìan representarse
> directamente en Smalltalk sin necesidad de mecanismos intermedios, derivando
> luego el modelo E-R o el modelo en tablas según sea necesario.
>
> Podrìas tener aplicaciones funcionando, cambiar las dependencias
> funcionales, y que la aplicación se adapte a los cambios sin necesidad de
> reprogramar nada ni de detener la aplicación.
>
> Para los que tengan dificultades entendiendo lo anterior, serìa factible
> hacer un generador de còdigo que genere interfaces de usuario, modelo de
> datos y migrador de datos en forma automática, aunque claramente prefiero
> que la aplicación no se detenga y siga funcionando sin necesidad de
> programar nada.
>
> Saludos,
> Guillermo.
>

> 2011/1/13 Juan <[hidden email]>

>
>
>
>
>
>
>
> > Hola gente
>
> > Bueno aporto un poco, creo que gaboto dijo algo claro y clave.
> > Tenes que pensar el dominio para modelarlo sin restricciones , lo de
> > la base de datos ,yo y quizas todo el mundo ,no se, lo llamo programacion
> > orientada al modelo de datos. o sea en bases de datos relacionales
> > se programa , los progamas son orientados a la representacion de los datos.
> > Entonces cuando cambias algun tipo de dato o definicion el programa sufre
> > cambios
> > a veces muy grandes.
> > El mapeo es una solucion intermedia. o sea se programa en "objetos" o en
> > lenguajes objetosos, excepto claro esta el smalltalk. y se mapea los
> > "objetos" a la db , teniendo
> > mas o menos exito.
> > En gral cuando se parte de esta formacion se tiende a mapear, una clase una
> > tabla una instancia una row.
> > Ese es el modelo de pensamiento que hay que romper, hay que pensar tu
> > objeto tu parte del modelo que necesita conocer? , las facturas ? ,ok. son
> > muchas ? bueno conocera una coleccion , y cada factura que necesita conocer?
> > , (por conocer digamos ,normalmente lo tiene o lo usa) podes arrancar con un
> > modelo exploratorio , en verdad deberias. y experimentar con los
> > colaboradores ( cosas q conoce otros objetos del dominio) e ir moviendolos
> > agregando sacando etc, hasta que pueda cumplir con su cometido ( el modelo
> > funcione) .
> > Luego pensa en la persistencia, no al reves. lo ultimo. o sea que el modelo
> > ande primero
> > luego la persistencia , asi como tambien te indicaron aqui y por
> > necesidades de perfomance u otras haces las "chanchadas" o sea ensucias a tu
> > modelo.
> > por ensuciar digamos que es la parte donde la persistencia afecta a tu
> > modelo .
> > bueno acoto hasta aca.
> > saludos
> > mdc
>

> > 2011/1/13 Gastón Dall' Oglio <[hidden email]>

>
> >> > Buenas, ya que estamos yo también me meto jeje.
>
> >> Buenas. Yo creo que la lista esta para que todo el que tenga algo que
> >> aportar lo haga :)
>
> >> Ya que estamos con el tema base de objetos y de datos, les consulto si
> >> alguno sabe que orientación tienen las bases de datos que se encuadran bajo
> >> el enfoque nosql. ¿Están tratando de hacer algo orientado a objetos o algo
> >> totalmente novedoso?
>
> >>http://nosql-database.org/
>

> >> El 13 de enero de 2011 10:58, Gaboto <[hidden email]> escribió:

>
> >> Buenas, ya que estamos yo también me meto jeje.
> >>> Solo un comentario. Para hacer un buen modelo en la base de objetos lo
> >>> que quizá deberías hacer es pensar en que tenés un programa en memoria y que
> >>> nunca se apaga. Es decir, imaginate que vos tenes que hacer un programa que
> >>> no tiene que persistir nada porque la compu siempre está prendida, Entonces,
> >>> en ese caso como harías? yo tendría las colecciones que correspondan y
> >>> agregaría algún diccionario por eficiencia, etc.
> >>> La consistencia del modelo la tendría que manejar el modelo mismo,
> >>> asegurandose de poner y sacar las cosas de las colecciones cuando
> >>> corresponda. No hay ningún trigger mágico ni nada de eso, que viene de otro
> >>> paradigma.
> >>> Yo creo que la idea de una base de objetos es justamente esa, hacer lo
> >>> más transparente posible la persistencia, aunque en realidad haya algunas
> >>> sutiles diferencias en la práctica...
> >>> Luego con el tiempo, como ya mencionaron acá, te vas a ir dando cuenta de
> >>> si hay que hacer alguna "chanchada" o algo para ir optimizando los tiempos.
>

> >>> 2011/1/13 Gastón Dall' Oglio <[hidden email]>

>
> >>>>  Muchas gracias por sus comentarios!
>
> >>>> Sí, el become ya me parecía una mala idea por lo que he leído.
>
> >>>> Saludos.
>

> >>>> El 13 de enero de 2011 08:48, Esteban Lorenzano <[hidden email]>escribió:

>
> >>>> hola,
> >>>>> bueno, me meto en el thread :)
> >>>>> IMHO, el problema es que seguís pensando tu estructura de datos en
> >>>>> relacional, no en objetos (por eso lo pensás como una estructura de datos y
> >>>>> no como un grafo de objetos, je).
> >>>>> Yo la primer pregunta que me haría es "para qué quiero la colección de
> >>>>> todas las facturas? las necesito, o es solo que 'me parece' que tienen que
> >>>>> estar en una colección aparte (como si la colección fuera una tabla)"
> >>>>> realmente me parece que es una instancia muy nueva de tu aplicación
> >>>>> (por lo que veo) para saber si realmente necesitas tener una colección de
> >>>>> facturas aparte. En estos momentos no hay nada que te impida hacer algo
> >>>>> como:
>
> >>>>> allInvoices
> >>>>>        ^self customers
> >>>>>                inject: Set new
> >>>>>                into: [ :all :each | all, each invoices ]
>
> >>>>> eso puede demostrarse no eficiente con el tiempo, pero también puede
> >>>>> demostrarse que no necesitás #allInvoices y entonces te ahorrás todo el
> >>>>> problema de mantener invoices en dos lugares.
> >>>>> Si pese a todo decidís que sí necesitas mantenerlo aparte, lo que te
> >>>>> recomiendo es lo mismo que te recomendó Andrés, y le agrego que, para borrar
> >>>>> facturas, hagas algo como:
>
> >>>>> Customer>>removeInvoice: anInvoice
> >>>>>        self invoices remove: anInvoice.
> >>>>>        IndexadorDeFacturas instance remove: anInvoice.
>
> >>>>> usar el become (forward o no), suele no ser una respuesta correcta.
> >>>>> Entre otras cosas porque te hace un scan de todos los objetos en memoria, en
> >>>>> pharo/squeak, dado que no tienen object table.
>
> >>>>> nunca dejes de pensar desde el punto de vista del modelo, olvidate de
> >>>>> pensar en la estructura!
>
> >>>>> Saludos,
> >>>>> Esteban
>
> >>>>> El 13/01/2011, a las 7:42a.m., andres escribió:
>
> >>>>> > Yo personalmente evitaría eso porque:
>
> >>>>> > 1. Estás asumiendo cosas sobre las colecciones que contienen a la
> >>>>> factura. Si el día de mañana se te ocurre cambiar el tipo de colecciones y
> >>>>> esas colecciones por algún motivo no pueden contener nils las rompés.
> >>>>> > 2. Tenés que redefinir el protocolo de colecciones para manejar tus
> >>>>> casos ad-hoc (ej. si tenés un array el #size ya no te sirve; tenés que hacer
> >>>>> (select:[..| noNil]) size).
> >>>>> > 3. Estás asumiendo que nadie mas referencia a la factura (ej. un
> >>>>> inspector, un reporte, un histórico de facturas, etc). Si así fuera rompés
> >>>>> todo.
> >>>>> > 4. Como regla genérica el #become no se debe usar para resolver
> >>>>> problemas de diseño; eso te lleva a una seguidilla de hackasos. Mejor es
> >>>>> definir alguien que sepa sincronizar bien las colecciones de facturas. Por
> >>>>> ejemplo, podés definir que el indexador global de facturas no puede agregar
> >>>>> o eliminar facturas, sólo el cliente lo hace. Entonces te queda:
>
> >>>>> > (private) IndexadorDeFacturas>>agregarFactura: unaFacura
> >>>>> >                                               self factuas add:
> >>>>> unaFactura.
>
> >>>>> > (public) Cliente>>agregarFactura: unaFacura
> >>>>> >                               self factuas add: unaFactura.
> >>>>> >                               IndexadorDeFacturas instance
> >>>>> agregarFactura: unaFacura.
>
> >>>>> > Si uno es lo suficientemente disciplinado como para no usar el
> >>>>> protocolo privado del indexador de facturas ya no hay problemas.
>
> >>>>> > IMHO es mucho menos esfuerzo hacer ese diseño que todo el quilombo
> >>>>> que te trae el become.
>
> >>>>> > HTH,
> >>>>> > Andrés
>
> >>>>> > Gastón Dall' Oglio escribió:
> >>>>> >> Hola gente.
> >>>>> >> Capaz es una burrada pero bueno, no me quiero quedar con las dudas.
> >>>>> >> Supongamos que tengo unaFactura que esta referenciada desde una
> >>>>> colección
> >>>>> >> perteneciente a un cliente (sus facturas) y también desde una
> >>>>> colección de
> >>>>> >> todas las facturas. Para el tema de resolver el "borrado en cascada"
> >>>>> puedo
> >>>>> >> hacer algo como:
> >>>>> >> unaFactura become: nil
> >>>>> >> 1) Esto me asegura que ya nadie la referencia, y será liberada.
> >>>>> >> 2) Ambas colecciones quedan con la misma cantidad de elementos, solo
> >>>>> que
> >>>>> >> ahora tienen una referencia a nil. Que exista una factura nil es
> >>>>> fácil de
> >>>>> >> ignorar con un #select: o permanente con un #removeAll:
> >>>>> >> 3) El tiempo normal que demora un #become: aumenta considerablemente
> >>>>> por
> >>>>> >> tratarse de objetos persistidos por Magma.
> >>>>> >> Saludos!
> >>>>> >> El 12 de enero de 2011 18:40, Hernán Morales Durand <

> >>>>> >> [hidden email]> escribió:
> >>>>> >>> Hola Gerard,
>
> >>>>> >>> El día 12 de enero de 2011 10:59, gerard <[hidden email]>

> >>>>> escribió:
> >>>>> >>>> Lo que hecho de menos es una "manera de hacer" estandar que
> >>>>> prevenga
>

> ...
>
> leer más »

--

To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

--
Saludos cordiales,

Guillermo Schwarz
Sun Certified Enterprise Architect

--

To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--

To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

Hola gente!

 

Diogenes, gracias por la respuesta… Si, es como hacen Prevlayer (en Java, sigo sin recordar el nombre) y Bamboo (en .NET), encolan los pedidos.

 

Ahora, llamemos a ese pedido, un commando. Cuando llega un commando, y lo atienden (por ejemplo, un commando que diga “quiero viajar de Miami a Los Angeles”) y comienza a comprar pasajes, taxis, hoteles (todos objetos en memoria, en una tranquila imagen de Smalltalk), y en el medio del pedido se dan cuenta que no hay aviones o no hay lugar en los hoteles, y ya fueron modificando el estado de algunos objetos, como vuelven atras?

 

Respuestas que imagino:

-        Lo hacen con dificultad ;-)

-        En Kaos no damos vuelta atras, Stalker! ;-)

-        Antes de ejecutar el commando validamos que este todo bien para atenderlo (pero en este caso me imagino que es casi duplicar el codigo, atraviesan por todo un arbol de objetos QUE VAN A SER afectados por el commando, y luego volver a recorrerlos para EJECUTAR el commando; aun asi me imagino casos donde el primer paso, la revision, no bastaria para quedar seguros que se puede hacer el Segundo paso, la ejecucion)

 

Les cuento algo de lo que hace Clojure (tendria que revisar bien si hacen reintento siempre o no): una transacciones sobre objetos, en memoria. Si desde el punto de ejecucion X algo falla, los objetos vuelven al estado en el que estaban al entrar en X.

 

Nos leemos!

 

Angel “Java” Lopez

http://www.ajlopez.com

http://twitter.com/ajlopez

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Diogenes Moreira
Sent: Tuesday, January 18, 2011 4:03 PM

To: [hidden email]
Subject: Re: [clubSmalltalk] Re: Programación con un gestor de base de datos orientado a objetos

 

Hola Angel:

 

Te contesto lo de la concurrencia...

 

En Smalltalk, como en cualquier otro lenguaje.. lo que se intenta hacer es modelar la realidad.. 

Sea desde una pagina web o sea cual fuera el ambiente, lo que hay que preguntarse es que se debería hacer en lo que estamos modelando. Es un error muy común,  creo que heredado de la época del client &server pensar transaccionalmente en términos técnicos, dado las limitaciones de los ambiente que generalmente estaban basados en un DB.

Definido el modelo de como vas operar, eso se representa en la aplicación.

 

Creo en tu caso estas modelando una cuenta bancaria, y lo que tendría que hacer la aplicación es encolar los requerimiento, como la gente hace cola en los banco :)..

 

Una de las grandes ventajas de trabajar en ambientes como smalltalks es que no te encontrar con los constrains tecnológicos que tenes en otros entornos.

 

Resumiendo como manejamos la concurrencia..la respuesta es depende del negocio..

 

(Una de las cosas que me maravilla día a día de la programar y pensar orientado a objetos es que las cosas son sencilla, y no como la quieren vende algunos :P )

 

Y contestando a Andres.. la persistencia...

 

En este caso la pregunta, es otro.. como hacer para persistir el estado de los objetos sin tener problema en la aplicación, o como salvar la imagen... en ese sentido podes tomar varias politicas.. como por ejemplo persistir la imagen en periodo de tiempo regulares o cuando se hacen cambios(caso que puede ser muy pesado) .. Esteban Lorenzano esta trabajando en un framework, para grabar image segments y luego consolidar los segmentos.. Pero entendemos que ahi la complejidad que tratamos de administrar es otra.. la de la persistencia.. no la de la concurrencia..

 

Saludos 

 

 

2011/1/18 Angel "Java" Lopez <[hidden email]>

Hola gente!

Me meto yo tambien en este thread ;-) ... cortito y al pie...

Rapidamente, NoSql tambien apunta a escalabilidad horizontal (pongo mas
maquinas, y atiendo mas clientes), concurrencia, tener varios servidores
donde estan los datos NoSQL, se cae uno, y todo sigue andando.

Mis enlaces (Julio 2010) sobre el tema, y un video/presentacion:
http://ajlopez.wordpress.com/2010/07/19/nosql-resources/

Enlaces mas nuevos que me interesaron en:
http://delicious.com/ajlopez/nosql

Algo que mencione en algun thread aca en esta lista, hmmm... con Mariano...
es: tener un Smalltalk corriendo en red de maquinas, no en UNA maquina....
The network is the machine ;-)

En NoSQL, seria algo como: the network is the database ;-)

Veo que mencionaron en este thread el de programar como si todo esta en
memoria.... Justamente, siempre recuerdo a Smalltalk en eso. De Nuevo,
mencionando a Smalltalk, NoSql, y Software Transactional Memory (algo
parecido a lo que presente en Smalltalks 2010):
http://msmvps.com/blogs/lopez/archive/2010/08/08/look-ma-no-database.aspx

Aprovecho a preguntar:

Si trabajan en Smalltalk todo en memoria (no Gemstone, no Magma, no nada...
todo en memoria local, simple imagen de Smalltalk), como manejan la
concurrencia? Que pasa si algun cliente/pagina web quiere hacer una
transferencia de cuenta a cuenta, y otro cliente/pagina web tambien?

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
On Behalf Of Esteban A. Maringolo
Sent: Tuesday, January 18, 2011 2:32 PM
To: [hidden email]
Subject: Re: [clubSmalltalk] Re: Programación con un gestor de base de datos
orientado a objetos

Acaso Smalltalk no es NoSQL desde el vamos?

NoSQL es la forma moderna de llamar a un shared dictionary/hashtable
anidado?

Saludos!

Esteban A. Maringolo



El día 18 de enero de 2011 12:00, Gastón Dall' Oglio
<[hidden email]> escribió:
> Yo no sigo opinando porque no me da el conocimiento para tanto... Igual
> agradezco sus opiniones.
>
> Y ya que toqué el tema NoSQL hice los deberes y encontré un artículo ()
una
> forma de acceder a una de estas bases desde Pharo, se los paso por si les
> interesa. Me viene al pelo como persistencia porque estamos evaluando
hacer
> una aplicación con mapas en Smalltalk y puede andar para almacenar
imágenes
> de lugares:)
>
http://miguel.leugim.com.mx/index.php/2010/03/31/accessing-cassandra-from-ph
aro/
> http://wiki.apache.org/cassandra/
>
> Saludos!
>
> El 16 de enero de 2011 18:08, Gaboto <[hidden email]> escribió:
>>
>> Pienso totalmente lo contrario.
>> Saludos
>>
>> 2011/1/16 Guillermo Schwarz <[hidden email]>
>>>
>>> tienes que leer respecto de lo que son las dependencias funcionales, ya
>>> que esa es la base del modelo relacional.
>>> una vez entendido eso, el resto se trata de: ¿en qué contextos se puede
>>> aplicar las dependencias funcionales?
>>> pues bien, hasta el momento, desde mi punto de vista, en todos. desde la
>>> generación de interfaces de usuario a la especificiación de
requerimientos,
>>> pasando por el modelamiento de bases de datos.
>>> saludos,
>>> Guillermo.
>>>
>>> 2011/1/16 gerard <[hidden email]>
>>>>
>>>> No he entendido nada :|
>>>>
>>>> Bueno, el primer párrafo si ;))
>>>>
>>>> Saludos
>>>>
>>>> On 16 ene, 15:00, Guillermo Schwarz <[hidden email]>
>>>> wrote:
>>>> > Me parece muy superficial la discusiòn.
>>>> >
>>>> > De partida el modelamiento de base de datos relacionales parte de la
>>>> > idea E.
>>>> > F. Codd (http://www.dcc.uchile.cl/~rbaeza/inf/codd.html) de modelar
>>>> > las
>>>> > dependencias funcionales
>>>> > (http://cs.gmu.edu/~aobaidi/spring-02/Normalization.ppt), que no son
otra
>>>> > cosa que pares X -> Y (como un Dictionary o un HashMap). Eso se puede
>>>> > representar directamente en Smalltalk.
>>>> >
>>>> > La representación E-R y la representación en tablas son sólo el
>>>> > resultado de
>>>> > tratar de convertir las dependencias funcionales en una
representación
>>>> > entendible por humanos y por máquinas respectivamente. Lo simpàtico
>>>> > del
>>>> > asunto es que las dependencias funcionales podrìan representarse
>>>> > directamente en Smalltalk sin necesidad de mecanismos intermedios,
>>>> > derivando
>>>> > luego el modelo E-R o el modelo en tablas según sea necesario.
>>>> >
>>>> > Podrìas tener aplicaciones funcionando, cambiar las dependencias
>>>> > funcionales, y que la aplicación se adapte a los cambios sin
necesidad
>>>> > de
>>>> > reprogramar nada ni de detener la aplicación.
>>>> >
>>>> > Para los que tengan dificultades entendiendo lo anterior, serìa
>>>> > factible
>>>> > hacer un generador de còdigo que genere interfaces de usuario, modelo
>>>> > de
>>>> > datos y migrador de datos en forma automática, aunque claramente
>>>> > prefiero
>>>> > que la aplicación no se detenga y siga funcionando sin necesidad de
>>>> > programar nada.
>>>> >
>>>> > Saludos,
>>>> > Guillermo.
>>>> >
>>>> > 2011/1/13 Juan <[hidden email]>
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > > Hola gente
>>>> >
>>>> > > Bueno aporto un poco, creo que gaboto dijo algo claro y clave.
>>>> > > Tenes que pensar el dominio para modelarlo sin restricciones , lo
de
>>>> > > la base de datos ,yo y quizas todo el mundo ,no se, lo llamo
>>>> > > programacion
>>>> > > orientada al modelo de datos. o sea en bases de datos relacionales
>>>> > > se programa , los progamas son orientados a la representacion de
los
>>>> > > datos.
>>>> > > Entonces cuando cambias algun tipo de dato o definicion el programa
>>>> > > sufre
>>>> > > cambios
>>>> > > a veces muy grandes.
>>>> > > El mapeo es una solucion intermedia. o sea se programa en "objetos"
>>>> > > o en
>>>> > > lenguajes objetosos, excepto claro esta el smalltalk. y se mapea
los
>>>> > > "objetos" a la db , teniendo
>>>> > > mas o menos exito.
>>>> > > En gral cuando se parte de esta formacion se tiende a mapear, una
>>>> > > clase una
>>>> > > tabla una instancia una row.
>>>> > > Ese es el modelo de pensamiento que hay que romper, hay que pensar
>>>> > > tu
>>>> > > objeto tu parte del modelo que necesita conocer? , las facturas ?
>>>> > > ,ok. son
>>>> > > muchas ? bueno conocera una coleccion , y cada factura que necesita
>>>> > > conocer?
>>>> > > , (por conocer digamos ,normalmente lo tiene o lo usa) podes
>>>> > > arrancar con un
>>>> > > modelo exploratorio , en verdad deberias. y experimentar con los
>>>> > > colaboradores ( cosas q conoce otros objetos del dominio) e ir
>>>> > > moviendolos
>>>> > > agregando sacando etc, hasta que pueda cumplir con su cometido ( el
>>>> > > modelo
>>>> > > funcione) .
>>>> > > Luego pensa en la persistencia, no al reves. lo ultimo. o sea que
el
>>>> > > modelo
>>>> > > ande primero
>>>> > > luego la persistencia , asi como tambien te indicaron aqui y por
>>>> > > necesidades de perfomance u otras haces las "chanchadas" o sea
>>>> > > ensucias a tu
>>>> > > modelo.
>>>> > > por ensuciar digamos que es la parte donde la persistencia afecta a
>>>> > > tu
>>>> > > modelo .
>>>> > > bueno acoto hasta aca.
>>>> > > saludos
>>>> > > mdc
>>>> >
>>>> > > 2011/1/13 Gastón Dall' Oglio <[hidden email]>
>>>> >
>>>> > >> > Buenas, ya que estamos yo también me meto jeje.
>>>> >
>>>> > >> Buenas. Yo creo que la lista esta para que todo el que tenga algo
>>>> > >> que
>>>> > >> aportar lo haga :)
>>>> >
>>>> > >> Ya que estamos con el tema base de objetos y de datos, les
consulto
>>>> > >> si
>>>> > >> alguno sabe que orientación tienen las bases de datos que se
>>>> > >> encuadran bajo
>>>> > >> el enfoque nosql. ¿Están tratando de hacer algo orientado a
objetos
>>>> > >> o algo
>>>> > >> totalmente novedoso?
>>>> >
>>>> > >>http://nosql-database.org/
>>>> >
>>>> > >> El 13 de enero de 2011 10:58, Gaboto <[hidden email]> escribió:
>>>> >
>>>> > >> Buenas, ya que estamos yo también me meto jeje.
>>>> > >>> Solo un comentario. Para hacer un buen modelo en la base de
>>>> > >>> objetos lo
>>>> > >>> que quizá deberías hacer es pensar en que tenés un programa en
>>>> > >>> memoria y que
>>>> > >>> nunca se apaga. Es decir, imaginate que vos tenes que hacer un
>>>> > >>> programa que
>>>> > >>> no tiene que persistir nada porque la compu siempre está
prendida,
>>>> > >>> Entonces,
>>>> > >>> en ese caso como harías? yo tendría las colecciones que
>>>> > >>> correspondan y
>>>> > >>> agregaría algún diccionario por eficiencia, etc.
>>>> > >>> La consistencia del modelo la tendría que manejar el modelo
mismo,
>>>> > >>> asegurandose de poner y sacar las cosas de las colecciones cuando
>>>> > >>> corresponda. No hay ningún trigger mágico ni nada de eso, que
>>>> > >>> viene de otro
>>>> > >>> paradigma.
>>>> > >>> Yo creo que la idea de una base de objetos es justamente esa,
>>>> > >>> hacer lo
>>>> > >>> más transparente posible la persistencia, aunque en realidad haya
>>>> > >>> algunas
>>>> > >>> sutiles diferencias en la práctica...
>>>> > >>> Luego con el tiempo, como ya mencionaron acá, te vas a ir dando
>>>> > >>> cuenta de
>>>> > >>> si hay que hacer alguna "chanchada" o algo para ir optimizando
los
>>>> > >>> tiempos.
>>>> >
>>>> > >>> 2011/1/13 Gastón Dall' Oglio <[hidden email]>
>>>> >
>>>> > >>>>  Muchas gracias por sus comentarios!
>>>> >
>>>> > >>>> Sí, el become ya me parecía una mala idea por lo que he leído.
>>>> >
>>>> > >>>> Saludos.
>>>> >
>>>> > >>>> El 13 de enero de 2011 08:48, Esteban Lorenzano
>>>> > >>>> <[hidden email]>escribió:
>>>> >
>>>> > >>>> hola,
>>>> > >>>>> bueno, me meto en el thread :)
>>>> > >>>>> IMHO, el problema es que seguís pensando tu estructura de datos
>>>> > >>>>> en
>>>> > >>>>> relacional, no en objetos (por eso lo pensás como una
estructura
>>>> > >>>>> de datos y
>>>> > >>>>> no como un grafo de objetos, je).
>>>> > >>>>> Yo la primer pregunta que me haría es "para qué quiero la
>>>> > >>>>> colección de
>>>> > >>>>> todas las facturas? las necesito, o es solo que 'me parece' que
>>>> > >>>>> tienen que
>>>> > >>>>> estar en una colección aparte (como si la colección fuera una
>>>> > >>>>> tabla)"
>>>> > >>>>> realmente me parece que es una instancia muy nueva de tu
>>>> > >>>>> aplicación
>>>> > >>>>> (por lo que veo) para saber si realmente necesitas tener una
>>>> > >>>>> colección de
>>>> > >>>>> facturas aparte. En estos momentos no hay nada que te impida
>>>> > >>>>> hacer algo
>>>> > >>>>> como:
>>>> >
>>>> > >>>>> allInvoices
>>>> > >>>>>        ^self customers
>>>> > >>>>>                inject: Set new
>>>> > >>>>>                into: [ :all :each | all, each invoices ]
>>>> >
>>>> > >>>>> eso puede demostrarse no eficiente con el tiempo, pero también
>>>> > >>>>> puede
>>>> > >>>>> demostrarse que no necesitás #allInvoices y entonces te ahorrás
>>>> > >>>>> todo el
>>>> > >>>>> problema de mantener invoices en dos lugares.
>>>> > >>>>> Si pese a todo decidís que sí necesitas mantenerlo aparte, lo
>>>> > >>>>> que te
>>>> > >>>>> recomiendo es lo mismo que te recomendó Andrés, y le agrego
que,
>>>> > >>>>> para borrar
>>>> > >>>>> facturas, hagas algo como:
>>>> >
>>>> > >>>>> Customer>>removeInvoice: anInvoice
>>>> > >>>>>        self invoices remove: anInvoice.
>>>> > >>>>>        IndexadorDeFacturas instance remove: anInvoice.
>>>> >
>>>> > >>>>> usar el become (forward o no), suele no ser una respuesta
>>>> > >>>>> correcta.
>>>> > >>>>> Entre otras cosas porque te hace un scan de todos los objetos
en
>>>> > >>>>> memoria, en
>>>> > >>>>> pharo/squeak, dado que no tienen object table.
>>>> >
>>>> > >>>>> nunca dejes de pensar desde el punto de vista del modelo,
>>>> > >>>>> olvidate de
>>>> > >>>>> pensar en la estructura!
>>>> >
>>>> > >>>>> Saludos,
>>>> > >>>>> Esteban
>>>> >
>>>> > >>>>> El 13/01/2011, a las 7:42a.m., andres escribió:
>>>> >
>>>> > >>>>> > Yo personalmente evitaría eso porque:
>>>> >
>>>> > >>>>> > 1. Estás asumiendo cosas sobre las colecciones que contienen
a
>>>> > >>>>> > la
>>>> > >>>>> factura. Si el día de mañana se te ocurre cambiar el tipo de
>>>> > >>>>> colecciones y
>>>> > >>>>> esas colecciones por algún motivo no pueden contener nils las
>>>> > >>>>> rompés.
>>>> > >>>>> > 2. Tenés que redefinir el protocolo de colecciones para
>>>> > >>>>> > manejar tus
>>>> > >>>>> casos ad-hoc (ej. si tenés un array el #size ya no te sirve;
>>>> > >>>>> tenés que hacer
>>>> > >>>>> (select:[..| noNil]) size).
>>>> > >>>>> > 3. Estás asumiendo que nadie mas referencia a la factura (ej.
>>>> > >>>>> > un
>>>> > >>>>> inspector, un reporte, un histórico de facturas, etc). Si así
>>>> > >>>>> fuera rompés
>>>> > >>>>> todo.
>>>> > >>>>> > 4. Como regla genérica el #become no se debe usar para
>>>> > >>>>> > resolver
>>>> > >>>>> problemas de diseño; eso te lleva a una seguidilla de hackasos.
>>>> > >>>>> Mejor es
>>>> > >>>>> definir alguien que sepa sincronizar bien las colecciones de
>>>> > >>>>> facturas. Por
>>>> > >>>>> ejemplo, podés definir que el indexador global de facturas no
>>>> > >>>>> puede agregar
>>>> > >>>>> o eliminar facturas, sólo el cliente lo hace. Entonces te
queda:
>>>> >
>>>> > >>>>> > (private) IndexadorDeFacturas>>agregarFactura: unaFacura
>>>> > >>>>> >                                               self factuas
>>>> > >>>>> > add:
>>>> > >>>>> unaFactura.
>>>> >
>>>> > >>>>> > (public) Cliente>>agregarFactura: unaFacura
>>>> > >>>>> >                               self factuas add: unaFactura.
>>>> > >>>>> >                               IndexadorDeFacturas instance
>>>> > >>>>> agregarFactura: unaFacura.
>>>> >
>>>> > >>>>> > Si uno es lo suficientemente disciplinado como para no usar
el
>>>> > >>>>> protocolo privado del indexador de facturas ya no hay
problemas.
>>>> >
>>>> > >>>>> > IMHO es mucho menos esfuerzo hacer ese diseño que todo el
>>>> > >>>>> > quilombo
>>>> > >>>>> que te trae el become.
>>>> >
>>>> > >>>>> > HTH,
>>>> > >>>>> > Andrés
>>>> >
>>>> > >>>>> > Gastón Dall' Oglio escribió:
>>>> > >>>>> >> Hola gente.
>>>> > >>>>> >> Capaz es una burrada pero bueno, no me quiero quedar con las
>>>> > >>>>> >> dudas.
>>>> > >>>>> >> Supongamos que tengo unaFactura que esta referenciada desde
>>>> > >>>>> >> una
>>>> > >>>>> colección
>>>> > >>>>> >> perteneciente a un cliente (sus facturas) y también desde
una
>>>> > >>>>> colección de
>>>> > >>>>> >> todas las facturas. Para el tema de resolver el "borrado en
>>>> > >>>>> >> cascada"
>>>> > >>>>> puedo
>>>> > >>>>> >> hacer algo como:
>>>> > >>>>> >> unaFactura become: nil
>>>> > >>>>> >> 1) Esto me asegura que ya nadie la referencia, y será
>>>> > >>>>> >> liberada.
>>>> > >>>>> >> 2) Ambas colecciones quedan con la misma cantidad de
>>>> > >>>>> >> elementos, solo
>>>> > >>>>> que
>>>> > >>>>> >> ahora tienen una referencia a nil. Que exista una factura
nil
>>>> > >>>>> >> es
>>>> > >>>>> fácil de
>>>> > >>>>> >> ignorar con un #select: o permanente con un #removeAll:
>>>> > >>>>> >> 3) El tiempo normal que demora un #become: aumenta
>>>> > >>>>> >> considerablemente
>>>> > >>>>> por
>>>> > >>>>> >> tratarse de objetos persistidos por Magma.
>>>> > >>>>> >> Saludos!
>>>> > >>>>> >> El 12 de enero de 2011 18:40, Hernán Morales Durand <
>>>> > >>>>> >> [hidden email]> escribió:
>>>> > >>>>> >>> Hola Gerard,
>>>> >
>>>> > >>>>> >>> El día 12 de enero de 2011 10:59, gerard
<[hidden email]>
>>>> > >>>>> escribió:
>>>> > >>>>> >>>> Lo que hecho de menos es una "manera de hacer" estandar
que
>>>> > >>>>> prevenga
>>>> >
>>>> > ...
>>>> >
>>>> > leer más »
>>>>
>>>> --
>>>> To post to this group, send email to [hidden email]
>>>> To unsubscribe from this group, send email to
>>>> [hidden email]
>>>>
>>>> http://www.clubSmalltalk.org
>>>
>>>
>>> --
>>> Saludos cordiales,
>>>
>>> Guillermo Schwarz
>>> Sun Certified Enterprise Architect
>>> --
>>> To post to this group, send email to [hidden email]
>>> To unsubscribe from this group, send email to
>>> [hidden email]
>>>
>>> http://www.clubSmalltalk.org
>>
>> --
>> To post to this group, send email to [hidden email]
>> To unsubscribe from this group, send email to
>> [hidden email]
>>
>> http://www.clubSmalltalk.org
>
> --
> To post to this group, send email to [hidden email]
> To unsubscribe from this group, send email to
> [hidden email]
>
> http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to
[hidden email]

http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

 

--

To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

Hola Angel.

1. Con respecto a mi mail anterior, creo que no quedo claro que el encolamiento de las transacciones es una restricción de negocio, no conozco los frameworks que nombras, pero aca no se trata de una restricción de construcción sino solo de modelar la realidad

2. Vamos al ejemplo que planteas.. Y empecemos por el principio, en tu sistemas tendrías que tener modelado cada uno de los conceptos que componen la realidad.. osea tenes objetos que modelan, cada uno pasos de tu viaje (pasaja taxi hoteles), pero tambien tenes que modelar la operación de reserva de cada uno y la suma de todas las operaciones que llamaremos Viaje para ser genericos.
Ahora bien vayamos al mundo real, que hace un operador turistico cuando tiene que coordinar este tipo de viajes??.. esa es la pregunta que tenes que hacer y de esa manera tenes que manejar las operaciones, o comando que realizas.
Entoces vas a tener dos grupos de objetos, los relacionados con la represantacion las cosas.. pasajes, taxis, hoteles.. y los relacionados los procesos de reservas.
Siendo mas implementativos, Viaje o (ViajeManager, para los javosos :P )o algun colaborador va a tener que saber manejar las vuelta atras de las operaciones y va tener que saber mantener su integredidad.
Esto lo podría implementar a través de Mementos (para los amantes de los patrones), o a través Announcements, donde los objetos cambien de estado ante el mensaje de finalidad la "Transaccion" o como se te de la gana, mientras en tu aplicación te aproximes los mas posible al comportamiento que ves en la realidad..en este caso el operador turistico.

3. Por ultimo un mensajito by Diogenes.. Aunque los frameworks son muy utiles y hacen nuestro caminos mas corto, no todo puede ser resueltos por ello (se lo dice un fanatico de Seaside y que mete algo de mano en el fork de Glorp de SqueakDBX), y tratar de meter las cosas con forceps para que entren en alguno, es perder la hermosa variedad que tiene nuestro mundo y las diversión de representarlo en sistemas.. Dejemos los RAD para los ABM..

Saludos

2011/1/18 Angel "Java" Lopez <[hidden email]>

Hola gente!

 

Diogenes, gracias por la respuesta… Si, es como hacen Prevlayer (en Java, sigo sin recordar el nombre) y Bamboo (en .NET), encolan los pedidos.

 

Ahora, llamemos a ese pedido, un commando. Cuando llega un commando, y lo atienden (por ejemplo, un commando que diga “quiero viajar de Miami a Los Angeles”) y comienza a comprar pasajes, taxis, hoteles (todos objetos en memoria, en una tranquila imagen de Smalltalk), y en el medio del pedido se dan cuenta que no hay aviones o no hay lugar en los hoteles, y ya fueron modificando el estado de algunos objetos, como vuelven atras?

 

Respuestas que imagino:

-        Lo hacen con dificultad ;-)

-        En Kaos no damos vuelta atras, Stalker! ;-)

-        Antes de ejecutar el commando validamos que este todo bien para atenderlo (pero en este caso me imagino que es casi duplicar el codigo, atraviesan por todo un arbol de objetos QUE VAN A SER afectados por el commando, y luego volver a recorrerlos para EJECUTAR el commando; aun asi me imagino casos donde el primer paso, la revision, no bastaria para quedar seguros que se puede hacer el Segundo paso, la ejecucion)

 

Les cuento algo de lo que hace Clojure (tendria que revisar bien si hacen reintento siempre o no): una transacciones sobre objetos, en memoria. Si desde el punto de ejecucion X algo falla, los objetos vuelven al estado en el que estaban al entrar en X.

 

Nos leemos!

 

Angel “Java” Lopez

http://www.ajlopez.com

http://twitter.com/ajlopez

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Diogenes Moreira
Sent: Tuesday, January 18, 2011 4:03 PM

To: [hidden email]
Subject: Re: [clubSmalltalk] Re: Programación con un gestor de base de datos orientado a objetos

 

Hola Angel:

 

Te contesto lo de la concurrencia...

 

En Smalltalk, como en cualquier otro lenguaje.. lo que se intenta hacer es modelar la realidad.. 

Sea desde una pagina web o sea cual fuera el ambiente, lo que hay que preguntarse es que se debería hacer en lo que estamos modelando. Es un error muy común,  creo que heredado de la época del client &server pensar transaccionalmente en términos técnicos, dado las limitaciones de los ambiente que generalmente estaban basados en un DB.

Definido el modelo de como vas operar, eso se representa en la aplicación.

 

Creo en tu caso estas modelando una cuenta bancaria, y lo que tendría que hacer la aplicación es encolar los requerimiento, como la gente hace cola en los banco :)..

 

Una de las grandes ventajas de trabajar en ambientes como smalltalks es que no te encontrar con los constrains tecnológicos que tenes en otros entornos.

 

Resumiendo como manejamos la concurrencia..la respuesta es depende del negocio..

 

(Una de las cosas que me maravilla día a día de la programar y pensar orientado a objetos es que las cosas son sencilla, y no como la quieren vende algunos :P )

 

Y contestando a Andres.. la persistencia...

 

En este caso la pregunta, es otro.. como hacer para persistir el estado de los objetos sin tener problema en la aplicación, o como salvar la imagen... en ese sentido podes tomar varias politicas.. como por ejemplo persistir la imagen en periodo de tiempo regulares o cuando se hacen cambios(caso que puede ser muy pesado) .. Esteban Lorenzano esta trabajando en un framework, para grabar image segments y luego consolidar los segmentos.. Pero entendemos que ahi la complejidad que tratamos de administrar es otra.. la de la persistencia.. no la de la concurrencia..

 

Saludos 

 

 

2011/1/18 Angel "Java" Lopez <[hidden email]>

Hola gente!

Me meto yo tambien en este thread ;-) ... cortito y al pie...

Rapidamente, NoSql tambien apunta a escalabilidad horizontal (pongo mas
maquinas, y atiendo mas clientes), concurrencia, tener varios servidores
donde estan los datos NoSQL, se cae uno, y todo sigue andando.

Mis enlaces (Julio 2010) sobre el tema, y un video/presentacion:
http://ajlopez.wordpress.com/2010/07/19/nosql-resources/

Enlaces mas nuevos que me interesaron en:
http://delicious.com/ajlopez/nosql

Algo que mencione en algun thread aca en esta lista, hmmm... con Mariano...
es: tener un Smalltalk corriendo en red de maquinas, no en UNA maquina....
The network is the machine ;-)

En NoSQL, seria algo como: the network is the database ;-)

Veo que mencionaron en este thread el de programar como si todo esta en
memoria.... Justamente, siempre recuerdo a Smalltalk en eso. De Nuevo,
mencionando a Smalltalk, NoSql, y Software Transactional Memory (algo
parecido a lo que presente en Smalltalks 2010):
http://msmvps.com/blogs/lopez/archive/2010/08/08/look-ma-no-database.aspx

Aprovecho a preguntar:

Si trabajan en Smalltalk todo en memoria (no Gemstone, no Magma, no nada...
todo en memoria local, simple imagen de Smalltalk), como manejan la
concurrencia? Que pasa si algun cliente/pagina web quiere hacer una
transferencia de cuenta a cuenta, y otro cliente/pagina web tambien?

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
On Behalf Of Esteban A. Maringolo
Sent: Tuesday, January 18, 2011 2:32 PM
To: [hidden email]
Subject: Re: [clubSmalltalk] Re: Programación con un gestor de base de datos
orientado a objetos

Acaso Smalltalk no es NoSQL desde el vamos?

NoSQL es la forma moderna de llamar a un shared dictionary/hashtable
anidado?

Saludos!

Esteban A. Maringolo



El día 18 de enero de 2011 12:00, Gastón Dall' Oglio
<[hidden email]> escribió:
> Yo no sigo opinando porque no me da el conocimiento para tanto... Igual
> agradezco sus opiniones.
>
> Y ya que toqué el tema NoSQL hice los deberes y encontré un artículo ()
una
> forma de acceder a una de estas bases desde Pharo, se los paso por si les
> interesa. Me viene al pelo como persistencia porque estamos evaluando
hacer
> una aplicación con mapas en Smalltalk y puede andar para almacenar
imágenes
> de lugares:)
>
http://miguel.leugim.com.mx/index.php/2010/03/31/accessing-cassandra-from-ph
aro/
> http://wiki.apache.org/cassandra/
>
> Saludos!
>
> El 16 de enero de 2011 18:08, Gaboto <[hidden email]> escribió:
>>
>> Pienso totalmente lo contrario.
>> Saludos
>>
>> 2011/1/16 Guillermo Schwarz <[hidden email]>
>>>
>>> tienes que leer respecto de lo que son las dependencias funcionales, ya
>>> que esa es la base del modelo relacional.
>>> una vez entendido eso, el resto se trata de: ¿en qué contextos se puede
>>> aplicar las dependencias funcionales?
>>> pues bien, hasta el momento, desde mi punto de vista, en todos. desde la
>>> generación de interfaces de usuario a la especificiación de
requerimientos,
>>> pasando por el modelamiento de bases de datos.
>>> saludos,
>>> Guillermo.
>>>
>>> 2011/1/16 gerard <[hidden email]>
>>>>
>>>> No he entendido nada :|
>>>>
>>>> Bueno, el primer párrafo si ;))
>>>>
>>>> Saludos
>>>>
>>>> On 16 ene, 15:00, Guillermo Schwarz <[hidden email]>
>>>> wrote:
>>>> > Me parece muy superficial la discusiòn.
>>>> >
>>>> > De partida el modelamiento de base de datos relacionales parte de la
>>>> > idea E.
>>>> > F. Codd (http://www.dcc.uchile.cl/~rbaeza/inf/codd.html) de modelar
>>>> > las
>>>> > dependencias funcionales
>>>> > (http://cs.gmu.edu/~aobaidi/spring-02/Normalization.ppt), que no son
otra
>>>> > cosa que pares X -> Y (como un Dictionary o un HashMap). Eso se puede
>>>> > representar directamente en Smalltalk.
>>>> >
>>>> > La representación E-R y la representación en tablas son sólo el
>>>> > resultado de
>>>> > tratar de convertir las dependencias funcionales en una
representación
>>>> > entendible por humanos y por máquinas respectivamente. Lo simpàtico
>>>> > del
>>>> > asunto es que las dependencias funcionales podrìan representarse
>>>> > directamente en Smalltalk sin necesidad de mecanismos intermedios,
>>>> > derivando
>>>> > luego el modelo E-R o el modelo en tablas según sea necesario.
>>>> >
>>>> > Podrìas tener aplicaciones funcionando, cambiar las dependencias
>>>> > funcionales, y que la aplicación se adapte a los cambios sin
necesidad
>>>> > de
>>>> > reprogramar nada ni de detener la aplicación.
>>>> >
>>>> > Para los que tengan dificultades entendiendo lo anterior, serìa
>>>> > factible
>>>> > hacer un generador de còdigo que genere interfaces de usuario, modelo
>>>> > de
>>>> > datos y migrador de datos en forma automática, aunque claramente
>>>> > prefiero
>>>> > que la aplicación no se detenga y siga funcionando sin necesidad de
>>>> > programar nada.
>>>> >
>>>> > Saludos,
>>>> > Guillermo.
>>>> >
>>>> > 2011/1/13 Juan <[hidden email]>
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > > Hola gente
>>>> >
>>>> > > Bueno aporto un poco, creo que gaboto dijo algo claro y clave.
>>>> > > Tenes que pensar el dominio para modelarlo sin restricciones , lo
de
>>>> > > la base de datos ,yo y quizas todo el mundo ,no se, lo llamo
>>>> > > programacion
>>>> > > orientada al modelo de datos. o sea en bases de datos relacionales
>>>> > > se programa , los progamas son orientados a la representacion de
los
>>>> > > datos.
>>>> > > Entonces cuando cambias algun tipo de dato o definicion el programa
>>>> > > sufre
>>>> > > cambios
>>>> > > a veces muy grandes.
>>>> > > El mapeo es una solucion intermedia. o sea se programa en "objetos"
>>>> > > o en
>>>> > > lenguajes objetosos, excepto claro esta el smalltalk. y se mapea
los
>>>> > > "objetos" a la db , teniendo
>>>> > > mas o menos exito.
>>>> > > En gral cuando se parte de esta formacion se tiende a mapear, una
>>>> > > clase una
>>>> > > tabla una instancia una row.
>>>> > > Ese es el modelo de pensamiento que hay que romper, hay que pensar
>>>> > > tu
>>>> > > objeto tu parte del modelo que necesita conocer? , las facturas ?
>>>> > > ,ok. son
>>>> > > muchas ? bueno conocera una coleccion , y cada factura que necesita
>>>> > > conocer?
>>>> > > , (por conocer digamos ,normalmente lo tiene o lo usa) podes
>>>> > > arrancar con un
>>>> > > modelo exploratorio , en verdad deberias. y experimentar con los
>>>> > > colaboradores ( cosas q conoce otros objetos del dominio) e ir
>>>> > > moviendolos
>>>> > > agregando sacando etc, hasta que pueda cumplir con su cometido ( el
>>>> > > modelo
>>>> > > funcione) .
>>>> > > Luego pensa en la persistencia, no al reves. lo ultimo. o sea que
el
>>>> > > modelo
>>>> > > ande primero
>>>> > > luego la persistencia , asi como tambien te indicaron aqui y por
>>>> > > necesidades de perfomance u otras haces las "chanchadas" o sea
>>>> > > ensucias a tu
>>>> > > modelo.
>>>> > > por ensuciar digamos que es la parte donde la persistencia afecta a
>>>> > > tu
>>>> > > modelo .
>>>> > > bueno acoto hasta aca.
>>>> > > saludos
>>>> > > mdc
>>>> >
>>>> > > 2011/1/13 Gastón Dall' Oglio <[hidden email]>
>>>> >
>>>> > >> > Buenas, ya que estamos yo también me meto jeje.
>>>> >
>>>> > >> Buenas. Yo creo que la lista esta para que todo el que tenga algo
>>>> > >> que
>>>> > >> aportar lo haga :)
>>>> >
>>>> > >> Ya que estamos con el tema base de objetos y de datos, les
consulto
>>>> > >> si
>>>> > >> alguno sabe que orientación tienen las bases de datos que se
>>>> > >> encuadran bajo
>>>> > >> el enfoque nosql. ¿Están tratando de hacer algo orientado a
objetos
>>>> > >> o algo
>>>> > >> totalmente novedoso?
>>>> >
>>>> > >>http://nosql-database.org/
>>>> >
>>>> > >> El 13 de enero de 2011 10:58, Gaboto <[hidden email]> escribió:
>>>> >
>>>> > >> Buenas, ya que estamos yo también me meto jeje.
>>>> > >>> Solo un comentario. Para hacer un buen modelo en la base de
>>>> > >>> objetos lo
>>>> > >>> que quizá deberías hacer es pensar en que tenés un programa en
>>>> > >>> memoria y que
>>>> > >>> nunca se apaga. Es decir, imaginate que vos tenes que hacer un
>>>> > >>> programa que
>>>> > >>> no tiene que persistir nada porque la compu siempre está
prendida,
>>>> > >>> Entonces,
>>>> > >>> en ese caso como harías? yo tendría las colecciones que
>>>> > >>> correspondan y
>>>> > >>> agregaría algún diccionario por eficiencia, etc.
>>>> > >>> La consistencia del modelo la tendría que manejar el modelo
mismo,
>>>> > >>> asegurandose de poner y sacar las cosas de las colecciones cuando
>>>> > >>> corresponda. No hay ningún trigger mágico ni nada de eso, que
>>>> > >>> viene de otro
>>>> > >>> paradigma.
>>>> > >>> Yo creo que la idea de una base de objetos es justamente esa,
>>>> > >>> hacer lo
>>>> > >>> más transparente posible la persistencia, aunque en realidad haya
>>>> > >>> algunas
>>>> > >>> sutiles diferencias en la práctica...
>>>> > >>> Luego con el tiempo, como ya mencionaron acá, te vas a ir dando
>>>> > >>> cuenta de
>>>> > >>> si hay que hacer alguna "chanchada" o algo para ir optimizando
los
>>>> > >>> tiempos.
>>>> >
>>>> > >>> 2011/1/13 Gastón Dall' Oglio <[hidden email]>
>>>> >
>>>> > >>>>  Muchas gracias por sus comentarios!
>>>> >
>>>> > >>>> Sí, el become ya me parecía una mala idea por lo que he leído.
>>>> >
>>>> > >>>> Saludos.
>>>> >
>>>> > >>>> El 13 de enero de 2011 08:48, Esteban Lorenzano
>>>> > >>>> <[hidden email]>escribió:
>>>> >
>>>> > >>>> hola,
>>>> > >>>>> bueno, me meto en el thread :)
>>>> > >>>>> IMHO, el problema es que seguís pensando tu estructura de datos
>>>> > >>>>> en
>>>> > >>>>> relacional, no en objetos (por eso lo pensás como una
estructura
>>>> > >>>>> de datos y
>>>> > >>>>> no como un grafo de objetos, je).
>>>> > >>>>> Yo la primer pregunta que me haría es "para qué quiero la
>>>> > >>>>> colección de
>>>> > >>>>> todas las facturas? las necesito, o es solo que 'me parece' que
>>>> > >>>>> tienen que
>>>> > >>>>> estar en una colección aparte (como si la colección fuera una
>>>> > >>>>> tabla)"
>>>> > >>>>> realmente me parece que es una instancia muy nueva de tu
>>>> > >>>>> aplicación
>>>> > >>>>> (por lo que veo) para saber si realmente necesitas tener una
>>>> > >>>>> colección de
>>>> > >>>>> facturas aparte. En estos momentos no hay nada que te impida
>>>> > >>>>> hacer algo
>>>> > >>>>> como:
>>>> >
>>>> > >>>>> allInvoices
>>>> > >>>>>        ^self customers
>>>> > >>>>>                inject: Set new
>>>> > >>>>>                into: [ :all :each | all, each invoices ]
>>>> >
>>>> > >>>>> eso puede demostrarse no eficiente con el tiempo, pero también
>>>> > >>>>> puede
>>>> > >>>>> demostrarse que no necesitás #allInvoices y entonces te ahorrás
>>>> > >>>>> todo el
>>>> > >>>>> problema de mantener invoices en dos lugares.
>>>> > >>>>> Si pese a todo decidís que sí necesitas mantenerlo aparte, lo
>>>> > >>>>> que te
>>>> > >>>>> recomiendo es lo mismo que te recomendó Andrés, y le agrego
que,
>>>> > >>>>> para borrar
>>>> > >>>>> facturas, hagas algo como:
>>>> >
>>>> > >>>>> Customer>>removeInvoice: anInvoice
>>>> > >>>>>        self invoices remove: anInvoice.
>>>> > >>>>>        IndexadorDeFacturas instance remove: anInvoice.
>>>> >
>>>> > >>>>> usar el become (forward o no), suele no ser una respuesta
>>>> > >>>>> correcta.
>>>> > >>>>> Entre otras cosas porque te hace un scan de todos los objetos
en
>>>> > >>>>> memoria, en
>>>> > >>>>> pharo/squeak, dado que no tienen object table.
>>>> >
>>>> > >>>>> nunca dejes de pensar desde el punto de vista del modelo,
>>>> > >>>>> olvidate de
>>>> > >>>>> pensar en la estructura!
>>>> >
>>>> > >>>>> Saludos,
>>>> > >>>>> Esteban
>>>> >
>>>> > >>>>> El 13/01/2011, a las 7:42a.m., andres escribió:
>>>> >
>>>> > >>>>> > Yo personalmente evitaría eso porque:
>>>> >
>>>> > >>>>> > 1. Estás asumiendo cosas sobre las colecciones que contienen
a
>>>> > >>>>> > la
>>>> > >>>>> factura. Si el día de mañana se te ocurre cambiar el tipo de
>>>> > >>>>> colecciones y
>>>> > >>>>> esas colecciones por algún motivo no pueden contener nils las
>>>> > >>>>> rompés.
>>>> > >>>>> > 2. Tenés que redefinir el protocolo de colecciones para
>>>> > >>>>> > manejar tus
>>>> > >>>>> casos ad-hoc (ej. si tenés un array el #size ya no te sirve;
>>>> > >>>>> tenés que hacer
>>>> > >>>>> (select:[..| noNil]) size).
>>>> > >>>>> > 3. Estás asumiendo que nadie mas referencia a la factura (ej.
>>>> > >>>>> > un
>>>> > >>>>> inspector, un reporte, un histórico de facturas, etc). Si así
>>>> > >>>>> fuera rompés
>>>> > >>>>> todo.
>>>> > >>>>> > 4. Como regla genérica el #become no se debe usar para
>>>> > >>>>> > resolver
>>>> > >>>>> problemas de diseño; eso te lleva a una seguidilla de hackasos.
>>>> > >>>>> Mejor es
>>>> > >>>>> definir alguien que sepa sincronizar bien las colecciones de
>>>> > >>>>> facturas. Por
>>>> > >>>>> ejemplo, podés definir que el indexador global de facturas no
>>>> > >>>>> puede agregar
>>>> > >>>>> o eliminar facturas, sólo el cliente lo hace. Entonces te
queda:
>>>> >
>>>> > >>>>> > (private) IndexadorDeFacturas>>agregarFactura: unaFacura
>>>> > >>>>> >                                               self factuas
>>>> > >>>>> > add:
>>>> > >>>>> unaFactura.
>>>> >
>>>> > >>>>> > (public) Cliente>>agregarFactura: unaFacura
>>>> > >>>>> >                               self factuas add: unaFactura.
>>>> > >>>>> >                               IndexadorDeFacturas instance
>>>> > >>>>> agregarFactura: unaFacura.
>>>> >
>>>> > >>>>> > Si uno es lo suficientemente disciplinado como para no usar
el
>>>> > >>>>> protocolo privado del indexador de facturas ya no hay
problemas.
>>>> >
>>>> > >>>>> > IMHO es mucho menos esfuerzo hacer ese diseño que todo el
>>>> > >>>>> > quilombo
>>>> > >>>>> que te trae el become.
>>>> >
>>>> > >>>>> > HTH,
>>>> > >>>>> > Andrés
>>>> >
>>>> > >>>>> > Gastón Dall' Oglio escribió:
>>>> > >>>>> >> Hola gente.
>>>> > >>>>> >> Capaz es una burrada pero bueno, no me quiero quedar con las
>>>> > >>>>> >> dudas.
>>>> > >>>>> >> Supongamos que tengo unaFactura que esta referenciada desde
>>>> > >>>>> >> una
>>>> > >>>>> colección
>>>> > >>>>> >> perteneciente a un cliente (sus facturas) y también desde
una
>>>> > >>>>> colección de
>>>> > >>>>> >> todas las facturas. Para el tema de resolver el "borrado en
>>>> > >>>>> >> cascada"
>>>> > >>>>> puedo
>>>> > >>>>> >> hacer algo como:
>>>> > >>>>> >> unaFactura become: nil
>>>> > >>>>> >> 1) Esto me asegura que ya nadie la referencia, y será
>>>> > >>>>> >> liberada.
>>>> > >>>>> >> 2) Ambas colecciones quedan con la misma cantidad de
>>>> > >>>>> >> elementos, solo
>>>> > >>>>> que
>>>> > >>>>> >> ahora tienen una referencia a nil. Que exista una factura
nil
>>>> > >>>>> >> es
>>>> > >>>>> fácil de
>>>> > >>>>> >> ignorar con un #select: o permanente con un #removeAll:
>>>> > >>>>> >> 3) El tiempo normal que demora un #become: aumenta
>>>> > >>>>> >> considerablemente
>>>> > >>>>> por
>>>> > >>>>> >> tratarse de objetos persistidos por Magma.
>>>> > >>>>> >> Saludos!
>>>> > >>>>> >> El 12 de enero de 2011 18:40, Hernán Morales Durand <
>>>> > >>>>> >> [hidden email]> escribió:
>>>> > >>>>> >>> Hola Gerard,
>>>> >
>>>> > >>>>> >>> El día 12 de enero de 2011 10:59, gerard
<[hidden email]>
>>>> > >>>>> escribió:
>>>> > >>>>> >>>> Lo que hecho de menos es una "manera de hacer" estandar
que
>>>> > >>>>> prevenga
>>>> >
>>>> > ...
>>>> >
>>>> > leer más »
>>>>
>>>> --
>>>> To post to this group, send email to [hidden email]
>>>> To unsubscribe from this group, send email to
>>>> [hidden email]
>>>>
>>>> http://www.clubSmalltalk.org
>>>
>>>
>>> --
>>> Saludos cordiales,
>>>
>>> Guillermo Schwarz
>>> Sun Certified Enterprise Architect
>>> --
>>> To post to this group, send email to [hidden email]
>>> To unsubscribe from this group, send email to
>>> [hidden email]
>>>
>>> http://www.clubSmalltalk.org
>>
>> --
>> To post to this group, send email to [hidden email]
>> To unsubscribe from this group, send email to
>> [hidden email]
>>
>> http://www.clubSmalltalk.org
>
> --
> To post to this group, send email to [hidden email]
> To unsubscribe from this group, send email to
> [hidden email]
>
> http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to
[hidden email]

http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

 

--

To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--

To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

En java se llama prevailer. La idea es guardar toda la bd al final en un archivo y leerla toda al comienzo. Esa idea es casi la misma de guardar la imagen de smalltalk, pero en este caso  solo de los objetos que "prevail".

Me parece mas interesante escribir esos objetos en un log. El log se puede escribir de manera asíncrona, de modo que tiene costo cero (en tiempo). Y cada cierto tiempo se puede escribir un checkpoint, de manera de limitar lo que se debe leer del archivo en caso de caídas.

Saludos,

Guillermo Schwarz.

El 18-01-2011, a las 16:35, "Angel \"Java\" Lopez" <[hidden email]> escribió:

Hola gente!

 

Diogenes, gracias por la respuesta… Si, es como hacen Prevlayer (en Java, sigo sin recordar el nombre) y Bamboo (en .NET), encolan los pedidos.

 

Ahora, llamemos a ese pedido, un commando. Cuando llega un commando, y lo atienden (por ejemplo, un commando que diga “quiero viajar de Miami a Los Angeles”) y comienza a comprar pasajes, taxis, hoteles (todos objetos en memoria, en una tranquila imagen de Smalltalk), y en el medio del pedido se dan cuenta que no hay aviones o no hay lugar en los hoteles, y ya fueron modificando el estado de algunos objetos, como vuelven atras?

 

Respuestas que imagino:

-        Lo hacen con dificultad ;-)

-        En Kaos no damos vuelta atras, Stalker! ;-)

-        Antes de ejecutar el commando validamos que este todo bien para atenderlo (pero en este caso me imagino que es casi duplicar el codigo, atraviesan por todo un arbol de objetos QUE VAN A SER afectados por el commando, y luego volver a recorrerlos para EJECUTAR el commando; aun asi me imagino casos donde el primer paso, la revision, no bastaria para quedar seguros que se puede hacer el Segundo paso, la ejecucion)

 

Les cuento algo de lo que hace Clojure (tendria que revisar bien si hacen reintento siempre o no): una transacciones sobre objetos, en memoria. Si desde el punto de ejecucion X algo falla, los objetos vuelven al estado en el que estaban al entrar en X.

 

Nos leemos!

 

Angel “Java” Lopez

http://www.ajlopez.com

http://twitter.com/ajlopez

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Diogenes Moreira
Sent: Tuesday, January 18, 2011 4:03 PM
To: [hidden email]
Subject: Re: [clubSmalltalk] Re: Programación con un gestor de base de datos orientado a objetos

 

Hola Angel:

 

Te contesto lo de la concurrencia...

 

En Smalltalk, como en cualquier otro lenguaje.. lo que se intenta hacer es modelar la realidad.. 

Sea desde una pagina web o sea cual fuera el ambiente, lo que hay que preguntarse es que se debería hacer en lo que estamos modelando. Es un error muy común,  creo que heredado de la época del client &server pensar transaccionalmente en términos técnicos, dado las limitaciones de los ambiente que generalmente estaban basados en un DB.

Definido el modelo de como vas operar, eso se representa en la aplicación.

 

Creo en tu caso estas modelando una cuenta bancaria, y lo que tendría que hacer la aplicación es encolar los requerimiento, como la gente hace cola en los banco :)..

 

Una de las grandes ventajas de trabajar en ambientes como smalltalks es que no te encontrar con los constrains tecnológicos que tenes en otros entornos.

 

Resumiendo como manejamos la concurrencia..la respuesta es depende del negocio..

 

(Una de las cosas que me maravilla día a día de la programar y pensar orientado a objetos es que las cosas son sencilla, y no como la quieren vende algunos :P )

 

Y contestando a Andres.. la persistencia...

 

En este caso la pregunta, es otro.. como hacer para persistir el estado de los objetos sin tener problema en la aplicación, o como salvar la imagen... en ese sentido podes tomar varias politicas.. como por ejemplo persistir la imagen en periodo de tiempo regulares o cuando se hacen cambios(caso que puede ser muy pesado) .. Esteban Lorenzano esta trabajando en un framework, para grabar image segments y luego consolidar los segmentos.. Pero entendemos que ahi la complejidad que tratamos de administrar es otra.. la de la persistencia.. no la de la concurrencia..

 

Saludos 

 

 

2011/1/18 Angel "Java" Lopez <[hidden email]>

Hola gente!

Me meto yo tambien en este thread ;-) ... cortito y al pie...

Rapidamente, NoSql tambien apunta a escalabilidad horizontal (pongo mas
maquinas, y atiendo mas clientes), concurrencia, tener varios servidores
donde estan los datos NoSQL, se cae uno, y todo sigue andando.

Mis enlaces (Julio 2010) sobre el tema, y un video/presentacion:
http://ajlopez.wordpress.com/2010/07/19/nosql-resources/

Enlaces mas nuevos que me interesaron en:
http://delicious.com/ajlopez/nosql

Algo que mencione en algun thread aca en esta lista, hmmm... con Mariano...
es: tener un Smalltalk corriendo en red de maquinas, no en UNA maquina....
The network is the machine ;-)

En NoSQL, seria algo como: the network is the database ;-)

Veo que mencionaron en este thread el de programar como si todo esta en
memoria.... Justamente, siempre recuerdo a Smalltalk en eso. De Nuevo,
mencionando a Smalltalk, NoSql, y Software Transactional Memory (algo
parecido a lo que presente en Smalltalks 2010):
http://msmvps.com/blogs/lopez/archive/2010/08/08/look-ma-no-database.aspx

Aprovecho a preguntar:

Si trabajan en Smalltalk todo en memoria (no Gemstone, no Magma, no nada...
todo en memoria local, simple imagen de Smalltalk), como manejan la
concurrencia? Que pasa si algun cliente/pagina web quiere hacer una
transferencia de cuenta a cuenta, y otro cliente/pagina web tambien?

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
On Behalf Of Esteban A. Maringolo
Sent: Tuesday, January 18, 2011 2:32 PM
To: [hidden email]
Subject: Re: [clubSmalltalk] Re: Programación con un gestor de base de datos
orientado a objetos

Acaso Smalltalk no es NoSQL desde el vamos?

NoSQL es la forma moderna de llamar a un shared dictionary/hashtable
anidado?

Saludos!

Esteban A. Maringolo



El día 18 de enero de 2011 12:00, Gastón Dall' Oglio
<[hidden email]> escribió:
> Yo no sigo opinando porque no me da el conocimiento para tanto... Igual
> agradezco sus opiniones.
>
> Y ya que toqué el tema NoSQL hice los deberes y encontré un artículo ()
una
> forma de acceder a una de estas bases desde Pharo, se los paso por si les
> interesa. Me viene al pelo como persistencia porque estamos evaluando
hacer
> una aplicación con mapas en Smalltalk y puede andar para almacenar
imágenes
> de lugares:)
>
http://miguel.leugim.com.mx/index.php/2010/03/31/accessing-cassandra-from-ph
aro/
> http://wiki.apache.org/cassandra/
>
> Saludos!
>
> El 16 de enero de 2011 18:08, Gaboto <[hidden email]> escribió:
>>
>> Pienso totalmente lo contrario.
>> Saludos
>>
>> 2011/1/16 Guillermo Schwarz <[hidden email]>
>>>
>>> tienes que leer respecto de lo que son las dependencias funcionales, ya
>>> que esa es la base del modelo relacional.
>>> una vez entendido eso, el resto se trata de: ¿en qué contextos se puede
>>> aplicar las dependencias funcionales?
>>> pues bien, hasta el momento, desde mi punto de vista, en todos. desde la
>>> generación de interfaces de usuario a la especificiación de
requerimientos,
>>> pasando por el modelamiento de bases de datos.
>>> saludos,
>>> Guillermo.
>>>
>>> 2011/1/16 gerard <[hidden email]>
>>>>
>>>> No he entendido nada :|
>>>>
>>>> Bueno, el primer párrafo si ;))
>>>>
>>>> Saludos
>>>>
>>>> On 16 ene, 15:00, Guillermo Schwarz <[hidden email]>
>>>> wrote:
>>>> > Me parece muy superficial la discusiòn.
>>>> >
>>>> > De partida el modelamiento de base de datos relacionales parte de la
>>>> > idea E.
>>>> > F. Codd (http://www.dcc.uchile.cl/~rbaeza/inf/codd.html) de modelar
>>>> > las
>>>> > dependencias funcionales
>>>> > (http://cs.gmu.edu/~aobaidi/spring-02/Normalization.ppt), que no son
otra
>>>> > cosa que pares X -> Y (como un Dictionary o un HashMap). Eso se puede
>>>> > representar directamente en Smalltalk.
>>>> >
>>>> > La representación E-R y la representación en tablas son sólo el
>>>> > resultado de
>>>> > tratar de convertir las dependencias funcionales en una
representación
>>>> > entendible por humanos y por máquinas respectivamente. Lo simpàtico
>>>> > del
>>>> > asunto es que las dependencias funcionales podrìan representarse
>>>> > directamente en Smalltalk sin necesidad de mecanismos intermedios,
>>>> > derivando
>>>> > luego el modelo E-R o el modelo en tablas según sea necesario.
>>>> >
>>>> > Podrìas tener aplicaciones funcionando, cambiar las dependencias
>>>> > funcionales, y que la aplicación se adapte a los cambios sin
necesidad
>>>> > de
>>>> > reprogramar nada ni de detener la aplicación.
>>>> >
>>>> > Para los que tengan dificultades entendiendo lo anterior, serìa
>>>> > factible
>>>> > hacer un generador de còdigo que genere interfaces de usuario, modelo
>>>> > de
>>>> > datos y migrador de datos en forma automática, aunque claramente
>>>> > prefiero
>>>> > que la aplicación no se detenga y siga funcionando sin necesidad de
>>>> > programar nada.
>>>> >
>>>> > Saludos,
>>>> > Guillermo.
>>>> >
>>>> > 2011/1/13 Juan <[hidden email]>
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > > Hola gente
>>>> >
>>>> > > Bueno aporto un poco, creo que gaboto dijo algo claro y clave.
>>>> > > Tenes que pensar el dominio para modelarlo sin restricciones , lo
de
>>>> > > la base de datos ,yo y quizas todo el mundo ,no se, lo llamo
>>>> > > programacion
>>>> > > orientada al modelo de datos. o sea en bases de datos relacionales
>>>> > > se programa , los progamas son orientados a la representacion de
los
>>>> > > datos.
>>>> > > Entonces cuando cambias algun tipo de dato o definicion el programa
>>>> > > sufre
>>>> > > cambios
>>>> > > a veces muy grandes.
>>>> > > El mapeo es una solucion intermedia. o sea se programa en "objetos"
>>>> > > o en
>>>> > > lenguajes objetosos, excepto claro esta el smalltalk. y se mapea
los
>>>> > > "objetos" a la db , teniendo
>>>> > > mas o menos exito.
>>>> > > En gral cuando se parte de esta formacion se tiende a mapear, una
>>>> > > clase una
>>>> > > tabla una instancia una row.
>>>> > > Ese es el modelo de pensamiento que hay que romper, hay que pensar
>>>> > > tu
>>>> > > objeto tu parte del modelo que necesita conocer? , las facturas ?
>>>> > > ,ok. son
>>>> > > muchas ? bueno conocera una coleccion , y cada factura que necesita
>>>> > > conocer?
>>>> > > , (por conocer digamos ,normalmente lo tiene o lo usa) podes
>>>> > > arrancar con un
>>>> > > modelo exploratorio , en verdad deberias. y experimentar con los
>>>> > > colaboradores ( cosas q conoce otros objetos del dominio) e ir
>>>> > > moviendolos
>>>> > > agregando sacando etc, hasta que pueda cumplir con su cometido ( el
>>>> > > modelo
>>>> > > funcione) .
>>>> > > Luego pensa en la persistencia, no al reves. lo ultimo. o sea que
el
>>>> > > modelo
>>>> > > ande primero
>>>> > > luego la persistencia , asi como tambien te indicaron aqui y por
>>>> > > necesidades de perfomance u otras haces las "chanchadas" o sea
>>>> > > ensucias a tu
>>>> > > modelo.
>>>> > > por ensuciar digamos que es la parte donde la persistencia afecta a
>>>> > > tu
>>>> > > modelo .
>>>> > > bueno acoto hasta aca.
>>>> > > saludos
>>>> > > mdc
>>>> >
>>>> > > 2011/1/13 Gastón Dall' Oglio <[hidden email]>
>>>> >
>>>> > >> > Buenas, ya que estamos yo también me meto jeje.
>>>> >
>>>> > >> Buenas. Yo creo que la lista esta para que todo el que tenga algo
>>>> > >> que
>>>> > >> aportar lo haga :)
>>>> >
>>>> > >> Ya que estamos con el tema base de objetos y de datos, les
consulto
>>>> > >> si
>>>> > >> alguno sabe que orientación tienen las bases de datos que se
>>>> > >> encuadran bajo
>>>> > >> el enfoque nosql. ¿Están tratando de hacer algo orientado a
objetos
>>>> > >> o algo
>>>> > >> totalmente novedoso?
>>>> >
>>>> > >>http://nosql-database.org/
>>>> >
>>>> > >> El 13 de enero de 2011 10:58, Gaboto <[hidden email]> escribió:
>>>> >
>>>> > >> Buenas, ya que estamos yo también me meto jeje.
>>>> > >>> Solo un comentario. Para hacer un buen modelo en la base de
>>>> > >>> objetos lo
>>>> > >>> que quizá deberías hacer es pensar en que tenés un programa en
>>>> > >>> memoria y que
>>>> > >>> nunca se apaga. Es decir, imaginate que vos tenes que hacer un
>>>> > >>> programa que
>>>> > >>> no tiene que persistir nada porque la compu siempre está
prendida,
>>>> > >>> Entonces,
>>>> > >>> en ese caso como harías? yo tendría las colecciones que
>>>> > >>> correspondan y
>>>> > >>> agregaría algún diccionario por eficiencia, etc.
>>>> > >>> La consistencia del modelo la tendría que manejar el modelo
mismo,
>>>> > >>> asegurandose de poner y sacar las cosas de las colecciones cuando
>>>> > >>> corresponda. No hay ningún trigger mágico ni nada de eso, que
>>>> > >>> viene de otro
>>>> > >>> paradigma.
>>>> > >>> Yo creo que la idea de una base de objetos es justamente esa,
>>>> > >>> hacer lo
>>>> > >>> más transparente posible la persistencia, aunque en realidad haya
>>>> > >>> algunas
>>>> > >>> sutiles diferencias en la práctica...
>>>> > >>> Luego con el tiempo, como ya mencionaron acá, te vas a ir dando
>>>> > >>> cuenta de
>>>> > >>> si hay que hacer alguna "chanchada" o algo para ir optimizando
los
>>>> > >>> tiempos.
>>>> >
>>>> > >>> 2011/1/13 Gastón Dall' Oglio <[hidden email]>
>>>> >
>>>> > >>>>  Muchas gracias por sus comentarios!
>>>> >
>>>> > >>>> Sí, el become ya me parecía una mala idea por lo que he leído.
>>>> >
>>>> > >>>> Saludos.
>>>> >
>>>> > >>>> El 13 de enero de 2011 08:48, Esteban Lorenzano
>>>> > >>>> <[hidden email]>escribió:
>>>> >
>>>> > >>>> hola,
>>>> > >>>>> bueno, me meto en el thread :)
>>>> > >>>>> IMHO, el problema es que seguís pensando tu estructura de datos
>>>> > >>>>> en
>>>> > >>>>> relacional, no en objetos (por eso lo pensás como una
estructura
>>>> > >>>>> de datos y
>>>> > >>>>> no como un grafo de objetos, je).
>>>> > >>>>> Yo la primer pregunta que me haría es "para qué quiero la
>>>> > >>>>> colección de
>>>> > >>>>> todas las facturas? las necesito, o es solo que 'me parece' que
>>>> > >>>>> tienen que
>>>> > >>>>> estar en una colección aparte (como si la colección fuera una
>>>> > >>>>> tabla)"
>>>> > >>>>> realmente me parece que es una instancia muy nueva de tu
>>>> > >>>>> aplicación
>>>> > >>>>> (por lo que veo) para saber si realmente necesitas tener una
>>>> > >>>>> colección de
>>>> > >>>>> facturas aparte. En estos momentos no hay nada que te impida
>>>> > >>>>> hacer algo
>>>> > >>>>> como:
>>>> >
>>>> > >>>>> allInvoices
>>>> > >>>>>        ^self customers
>>>> > >>>>>                inject: Set new
>>>> > >>>>>                into: [ :all :each | all, each invoices ]
>>>> >
>>>> > >>>>> eso puede demostrarse no eficiente con el tiempo, pero también
>>>> > >>>>> puede
>>>> > >>>>> demostrarse que no necesitás #allInvoices y entonces te ahorrás
>>>> > >>>>> todo el
>>>> > >>>>> problema de mantener invoices en dos lugares.
>>>> > >>>>> Si pese a todo decidís que sí necesitas mantenerlo aparte, lo
>>>> > >>>>> que te
>>>> > >>>>> recomiendo es lo mismo que te recomendó Andrés, y le agrego
que,
>>>> > >>>>> para borrar
>>>> > >>>>> facturas, hagas algo como:
>>>> >
>>>> > >>>>> Customer>>removeInvoice: anInvoice
>>>> > >>>>>        self invoices remove: anInvoice.
>>>> > >>>>>        IndexadorDeFacturas instance remove: anInvoice.
>>>> >
>>>> > >>>>> usar el become (forward o no), suele no ser una respuesta
>>>> > >>>>> correcta.
>>>> > >>>>> Entre otras cosas porque te hace un scan de todos los objetos
en
>>>> > >>>>> memoria, en
>>>> > >>>>> pharo/squeak, dado que no tienen object table.
>>>> >
>>>> > >>>>> nunca dejes de pensar desde el punto de vista del modelo,
>>>> > >>>>> olvidate de
>>>> > >>>>> pensar en la estructura!
>>>> >
>>>> > >>>>> Saludos,
>>>> > >>>>> Esteban
>>>> >
>>>> > >>>>> El 13/01/2011, a las 7:42a.m., andres escribió:
>>>> >
>>>> > >>>>> > Yo personalmente evitaría eso porque:
>>>> >
>>>> > >>>>> > 1. Estás asumiendo cosas sobre las colecciones que contienen
a
>>>> > >>>>> > la
>>>> > >>>>> factura. Si el día de mañana se te ocurre cambiar el tipo de
>>>> > >>>>> colecciones y
>>>> > >>>>> esas colecciones por algún motivo no pueden contener nils las
>>>> > >>>>> rompés.
>>>> > >>>>> > 2. Tenés que redefinir el protocolo de colecciones para
>>>> > >>>>> > manejar tus
>>>> > >>>>> casos ad-hoc (ej. si tenés un array el #size ya no te sirve;
>>>> > >>>>> tenés que hacer
>>>> > >>>>> (select:[..| noNil]) size).
>>>> > >>>>> > 3. Estás asumiendo que nadie mas referencia a la factura (ej.
>>>> > >>>>> > un
>>>> > >>>>> inspector, un reporte, un histórico de facturas, etc). Si así
>>>> > >>>>> fuera rompés
>>>> > >>>>> todo.
>>>> > >>>>> > 4. Como regla genérica el #become no se debe usar para
>>>> > >>>>> > resolver
>>>> > >>>>> problemas de diseño; eso te lleva a una seguidilla de hackasos.
>>>> > >>>>> Mejor es
>>>> > >>>>> definir alguien que sepa sincronizar bien las colecciones de
>>>> > >>>>> facturas. Por
>>>> > >>>>> ejemplo, podés definir que el indexador global de facturas no
>>>> > >>>>> puede agregar
>>>> > >>>>> o eliminar facturas, sólo el cliente lo hace. Entonces te
queda:
>>>> >
>>>> > >>>>> > (private) IndexadorDeFacturas>>agregarFactura: unaFacura
>>>> > >>>>> >                                               self factuas
>>>> > >>>>> > add:
>>>> > >>>>> unaFactura.
>>>> >
>>>> > >>>>> > (public) Cliente>>agregarFactura: unaFacura
>>>> > >>>>> >                               self factuas add: unaFactura.
>>>> > >>>>> >                               IndexadorDeFacturas instance
>>>> > >>>>> agregarFactura: unaFacura.
>>>> >
>>>> > >>>>> > Si uno es lo suficientemente disciplinado como para no usar
el
>>>> > >>>>> protocolo privado del indexador de facturas ya no hay
problemas.
>>>> >
>>>> > >>>>> > IMHO es mucho menos esfuerzo hacer ese diseño que todo el
>>>> > >>>>> > quilombo
>>>> > >>>>> que te trae el become.
>>>> >
>>>> > >>>>> > HTH,
>>>> > >>>>> > Andrés
>>>> >
>>>> > >>>>> > Gastón Dall' Oglio escribió:
>>>> > >>>>> >> Hola gente.
>>>> > >>>>> >> Capaz es una burrada pero bueno, no me quiero quedar con las
>>>> > >>>>> >> dudas.
>>>> > >>>>> >> Supongamos que tengo unaFactura que esta referenciada desde
>>>> > >>>>> >> una
>>>> > >>>>> colección
>>>> > >>>>> >> perteneciente a un cliente (sus facturas) y también desde
una
>>>> > >>>>> colección de
>>>> > >>>>> >> todas las facturas. Para el tema de resolver el "borrado en
>>>> > >>>>> >> cascada"
>>>> > >>>>> puedo
>>>> > >>>>> >> hacer algo como:
>>>> > >>>>> >> unaFactura become: nil
>>>> > >>>>> >> 1) Esto me asegura que ya nadie la referencia, y será
>>>> > >>>>> >> liberada.
>>>> > >>>>> >> 2) Ambas colecciones quedan con la misma cantidad de
>>>> > >>>>> >> elementos, solo
>>>> > >>>>> que
>>>> > >>>>> >> ahora tienen una referencia a nil. Que exista una factura
nil
>>>> > >>>>> >> es
>>>> > >>>>> fácil de
>>>> > >>>>> >> ignorar con un #select: o permanente con un #removeAll:
>>>> > >>>>> >> 3) El tiempo normal que demora un #become: aumenta
>>>> > >>>>> >> considerablemente
>>>> > >>>>> por
>>>> > >>>>> >> tratarse de objetos persistidos por Magma.
>>>> > >>>>> >> Saludos!
>>>> > >>>>> >> El 12 de enero de 2011 18:40, Hernán Morales Durand <
>>>> > >>>>> >> [hidden email]> escribió:
>>>> > >>>>> >>> Hola Gerard,
>>>> >
>>>> > >>>>> >>> El día 12 de enero de 2011 10:59, gerard
<[hidden email]>
>>>> > >>>>> escribió:
>>>> > >>>>> >>>> Lo que hecho de menos es una "manera de hacer" estandar
que
>>>> > >>>>> prevenga
>>>> >
>>>> > ...
>>>> >
>>>> > leer más »
>>>>
>>>> --
>>>> To post to this group, send email to [hidden email]
>>>> To unsubscribe from this group, send email to
>>>> [hidden email]
>>>>
>>>> http://www.clubSmalltalk.org
>>>
>>>
>>> --
>>> Saludos cordiales,
>>>
>>> Guillermo Schwarz
>>> Sun Certified Enterprise Architect
>>> --
>>> To post to this group, send email to [hidden email]
>>> To unsubscribe from this group, send email to
>>> [hidden email]
>>>
>>> http://www.clubSmalltalk.org
>>
>> --
>> To post to this group, send email to [hidden email]
>> To unsubscribe from this group, send email to
>> [hidden email]
>>
>> http://www.clubSmalltalk.org
>
> --
> To post to this group, send email to [hidden email]
> To unsubscribe from this group, send email to
> [hidden email]
>
> http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to
[hidden email]

http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

 

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--

To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org