On Mar 21, 12:39 pm, Guillermo Sapaya <[EMAIL PROTECTED]> wrote:
> Hola Sebastián!
>
> Sebastian escribió:> Bueno, ya me suscribí a la lista Glorp para preguntarles
> directamente
> > a ellos. La verdad que voy a ver un poco lo de Magrite y el
> > ActiveRecord de Ramon Leon a ver si ayudan porque anoche estuve
> > viendo el tutorial del Glorp y la verdad que mi corage por usarlo no
> > es el mismo.
>
> JAJAJA!!! A mi me pasó EXACTAMENTE lo mismo!!! Estoy contento porque veo
> que hay otros que piensan igual que yo.
> En mi caso lo que me pasó es algo muy parecido a lo que decís acá:> La
> pregunta del millón es: es posible usar glorp de forma que te
> > permita no tener que pensar en "relacionalés"?
>
> Esoesoesoeso (diría el Chavo)! Sentí (al igual que con otras soluciones
> propuestas) como que se presta "demasiada" atención y se gastan todas
> las fichas en todo lo que hace a la BD relacional dejando Smalltalk
> solamente como lenguaje de sooprte para pasar los datos de una BD a objetos.
> IMO la visión debería ser al revés: Tengo un ambiente de objetos que
> quiero persistirlo en una relacional. Voy a hacer lo mínimo
> indispensable para que eso suceda (de la mejor manera).
> Por eso pienso que la dirección de como mirarlo es al revés, tengo toda
> la potencia de objetos vivos y voy a pasarlos a una relacional, pero
> pongo el máximo esfuerzo en esto y no en tooooodos los problemas que
> acarrea el hecho de trabajar con una relacional, de eso que se encargue
> el DBA.
> Por ejemplo:
> ¿Vale la pena invertir tantos esfuerzos en ver cómo modelar en mi Fw. de
> persistencia sentencias y funciones SQL que luego nunca voy a usar?
> ¿Tiene sentido poder "armar todo tipo de consultas SQL" desde mi fw.?
> Mi experiencia trabajando con objetos me dice que todo lo que necesito
> para trabajar de la manera mas transparente posible con una relacional
> es poder:
>
> - Leer objetos
> - Almacenar objetos
> - Borrar objetos
> - Joins básicos
> - Alguna que otra función SQL para acotar consultas
> - Manejo de transacciones y concurrencia
>
> Pueden agregarle algunas otras miscelaneas a tener en cuenta pero...
> Nada mas!!! Para todo lo otro tengo los objetos!
> En mi caso me pone mal ver tanta complejidad de entrada para resolver
> cosas tan simples como lo que expuse acá arriba, prefiero hacerlo de una
> manera simple pero elegante. Es por eso que acá decidimos hacer nuestro
> propio Fw. de persistencia y sinceramente hasta hoy día que ya tenemos
> sistemas en productivo usando dicho Fw. creo que fue una de las mejores
> decisiones que tomamos.
> El fw. es obviamente ajeno a todo nuestro dominio de negocios y se puede
> usar en cualquier tipo de sistema transaccional. Por el momento
> contempla todas las situaciones posibles que se nos presentaron hasta
> hoy en día y a medida que van apareciendo nuevas las vamos contemplando
> dentro del fw. Como ventajas le veo muchísimas, las principales:
>
> - Simpleza, las clases mínimas y necesarias para mapear objetos a una BD.
> - Contar con herramientas propias montadas sobre el Fw. que permiten a
> cualquier desarrollador definir de una manera MUY sencilla la interface
> de los objetos con la BD.
> - Facilidad y entendimiento a la hora agregarle funcionalidad al mismo o
> modificarlo. Pero como dije antes, no agregamos cualquier caso de SQL en
> el Fw. Lo primero que se analiza es si hace falta contemplar dicho caso
> en el fw. o se puede resolver mejor con lo que nosotros mas sabemos
> trabajar; con Objetos!
>
Muy interesante Guiye. Yo también me gasté en hacer un pequeño
framework pero hoy (por las razones que mencionaba en el otro thread)
veo que apostar en soportarse por OmniBase no tiene tanto valor como
el que juzgué en su momento. De cualquier forma conseguí llegar a
features interesantes como indexación arbitraria y no obligar a
subclasificar X clase a lo que se quiere persistir. Además de los
indices comunes la perlita que logré hacer es una implementación de un
índice especializado basado en Cheshire II de Berkeley para que las
aplicaciones tengan búsqueda no booleana (búsquedas probabilisticas).
Suena "fachuloqui" pero no es difícil. La papa de eso está en la
ecuación de scoring que hagas. Básicamente la magia del Google está en
su filesystem (que escala horizontalmente y si bien es relacional no
está soportado por RDBMS's) y en su ecuación de scoring que tiene como
50 términos (y probablemente sean dinámicos). Es decir Google
implementó con éxito un modelo de la escala de valores del consumidor
que tul eh?
Dicho eso y volviendo a nuestro empeño por evitar el pensamiento en
"relacionalés" nos vas a decir si es codigo que liberaste o nos vas a
dejar babando y llorando?
>
> > Así como está te resuelve persistencia pero te hace usar el smalltalk
> > como si de smalltalk no tuviera más que la sintaxis. No tengo interés
> > en aprender un nuevo dialecto relacional hablado en smalltalk. Un
> > poroto para Gemstone...
>
> Jeje, es lo que nos pasó a nosotros luego de analizar reStore, GLORP y
> otros fw. de mapeo/persistencia realizados en otras tecnologías.
>
> > saludos,
>
> > Sebastian
>
> Abrazo, Guiye
>
> --
> Guillermo Sapaya
> InfOil S.A.
> Gerente de Desarrollo
> (+54-11) 4542-9999 x106
> [EMAIL PROTECTED]
--~--~---------~--~----~------------~-------~--~----~
Has recibido este mensaje porque estás suscrito a Grupo "clubSmalltalk" de
Grupos de Google.
Si quieres publicar en este grupo, envía un mensaje de correo
electrónico a [email protected]
Para anular la suscripción a este grupo, envía un mensaje a [EMAIL PROTECTED]
Para obtener más opciones, visita este grupo en
http://groups.google.com/group/clubSmalltalk?hl=es.
-~----------~----~----~----~------~----~------~--~---
