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 <[email protected]> > 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: [email protected] [mailto: > [email protected]] > On Behalf Of Esteban A. Maringolo > Sent: Tuesday, January 18, 2011 2:32 PM > To: [email protected] > 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 > <[email protected]> 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 <[email protected]> escribió: > >> > >> Pienso totalmente lo contrario. > >> Saludos > >> > >> 2011/1/16 Guillermo Schwarz <[email protected]> > >>> > >>> 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 <[email protected]> > >>>> > >>>> No he entendido nada :| > >>>> > >>>> Bueno, el primer párrafo si ;)) > >>>> > >>>> Saludos > >>>> > >>>> On 16 ene, 15:00, Guillermo Schwarz <[email protected]> > >>>> 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 <[email protected]> > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > 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 <[email protected]> > >>>> > > >>>> > >> > 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 <[email protected]> > 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 <[email protected]> > >>>> > > >>>> > >>>> 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 > >>>> > >>>> <[email protected]>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 < > >>>> > >>>>> >> [email protected]> escribió: > >>>> > >>>>> >>> Hola Gerard, > >>>> > > >>>> > >>>>> >>> El día 12 de enero de 2011 10:59, gerard > <[email protected]> > >>>> > >>>>> 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 [email protected] > >>>> To unsubscribe from this group, send email to > >>>> [email protected]<clubsmalltalk%[email protected]> > >>>> > >>>> http://www.clubSmalltalk.org > >>> > >>> > >>> -- > >>> Saludos cordiales, > >>> > >>> Guillermo Schwarz > >>> Sun Certified Enterprise Architect > >>> -- > >>> To post to this group, send email to [email protected] > >>> To unsubscribe from this group, send email to > >>> [email protected]<clubsmalltalk%[email protected]> > >>> > >>> http://www.clubSmalltalk.org > >> > >> -- > >> To post to this group, send email to [email protected] > >> To unsubscribe from this group, send email to > >> [email protected]<clubsmalltalk%[email protected]> > >> > >> http://www.clubSmalltalk.org > > > > -- > > To post to this group, send email to [email protected] > > To unsubscribe from this group, send email to > > [email protected]<clubsmalltalk%[email protected]> > > > > http://www.clubSmalltalk.org > > -- > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected]<clubsmalltalk%[email protected]> > > http://www.clubSmalltalk.org > > -- > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected]<clubsmalltalk%[email protected]> > > http://www.clubSmalltalk.org -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
