Hola Ramiro,
Actualmente estoy desarrollando un aplicativo comercial sobre
Squeak/Seaside. Hasta ahora tengo buenos resultados, debo admitir que
renegé un poco, es el precio de no pagar nada ;-), pero también es la
buena experiencia de "tener el poder" y no depender de nadie. Con el
tiempo eso es lo más apreciado, pues la energía que le pusiste al
principio se tornó en una excelente inversión a futuro.
Con respecto a Dolphin, me parece que es un excelente ambiente,
claró está que es solo para Windows, y con ello tenés una herramienta
muy barata para competir contra las herramientas tradicionales RAD (VB,
Delphi) en plataformas Windows.
Saludos,
Hernán.-
> -----Mensaje original-----
> De: [email protected]
> [mailto:[EMAIL PROTECTED] En nombre de Ramiro
> Diaz Trepat
> Enviado el: Martes, 08 de Agosto de 2006 03:49 p.m.
> Para: [email protected]
> Asunto: [clubSmalltalk] Re: lista y dialecto (era: OmniBase)
>
>
>
> Gracias Hernán y a todos los demás por la información super
> rica y experiencias. La verdad, recién me inscribo, pero
> según parece esta lista está buenísima. Hay mucha mas gente
> de la que me imaginaba, buena onda y experiencia. Según
> parece, muchos aca usan Dolphin y VisualWorks. ¿Los usan en
> ambientes laborales? ¿nadie se animó con el Squeak? ¿es peor
> en que aspectos? ¿Dolphin, funciona sólo en Windows? si es
> asi, esto ya lo descarta de mi horizonte. Saludos y gracias
> nuevamente.
>
> r.
>
>
>
>
> On 8/7/06, Hernán Galante <[EMAIL PROTECTED]> wrote:
> >
> > Hola,
> > Hace un buen tiempo que trabajo con Gemstone/S, con lo cual
> > puedo contar algunas experiencias. Nunca he usado un esquema tipo
> > Omnibase ni otro esquema de persistencia pasivo en forma
> comercial y
> > por bastante tiempo, con lo cual me limito a opinar sobre
> Gemstone/S.
> > El trabajo es muy diferente a usar una base SQL. El
> trabajar
> > con objetos no es fácil de entender y a mucha gente le deja más
> > tranquila hacer un SQL y ver sus datos ahi tranquilitos, sin que
> > ninguna magia de GC se los vuele :-)
> > Una cosa es que en un esquema de objeto JAMAS tenés un join
> > largo, si pasa esto es porque se está violando la
> encapsulación de los
> > objetos del modelo en algún lugar o falta que otros objetos se
> > conozcan entre si, etc.
> > No me imagino otra manera de poder escribir una consulta en
> > Smalltalk larga.
> > Los problemas que podés encontrar en un esquema de
> > persistencia con objetos son:
> >
> > a) Congestión de la red. Traerse los objetos al
> cliente y el
> > problema que ocasiona que los objetos viajen por la red. Entonces
> > tenés mecanismos de proxies que ayudan a que solo viaje lo
> > estrictamente necesario.
> >
> > b) Espacio en disco. Generalmente crecen mucho con la
> > actividad de las transacciones, se crea mucha basura que luego es
> > actividad del GC, los extents se agrandan y la única manera
> de bajar
> > el espacio ocupado en disco por los extents de una base es un
> > Backup/Restore. Esto es por la arquitectura multigeneracional que
> > usan. El único motor SQL que sabía que era multigeneracional era
> > Interbase, y también se resolvían muchos problemas de la
> misma manera
> > que en Gemstone (Sweep + B/R).
> >
> > c) Actividad del GC. Cuando hay mucha actividad en
> la base se
> > genera mucha basura, esta cantidad de basura genera mucha actividad
> > del GC. Como sabemos un GC es un proceso de mucho stress en el
> > ambiente con lo cual puede tirar abajo la performance. Para evitar
> > esto hay muchas técnicas, por ejemplo, Gemstone/S tiene 5 tipos
> > diferentes de GC, que ayudanm a aliviar esta actividad. También hay
> > otra técnica en la se puede desactivar el GC, a costo de consumir
> > disco, y en una base espejo paralela ir corriendo en GC, marcar los
> > OOP de los objetos que van a morir y luego correrla (en
> horarios con
> > menos actividad) sobre la base productiva.
> >
> > Como se ve, hay muchas cosas por las que preocuparse en una
> > BO, y ninguna tiene que ver con los problemas que se sucitan en un
> > motor SQL.
> > Con respecto a lo que decía Ramiro, seguramente se
> refiere al
> > punto a), traerte todo la colección de objetos persistentes
> al cliente
> > para luego consultarlo y quedarte con uno, es una locura.
> Si la red es
> > local, quizás ni se note, pero si es Wan puede ser que
> tarde siglos en
> > moverse, y es lógico. Lo que el menciona sería un
> remotePerform: en la
> > base. Esto lo provee Gemstone/S, o la otra solución es
> traer proxies,
> > y que estos a medida que vas consultando vaya trayendo de manera
> > onDemand lo que requiere. Hay varias técnicas de resolución.
> >
> > Saludos,
> > Hernán.-
> >
> > Pd. Es un tema muy interesante :-)
> >
> > -----Mensaje original-----
> > De: [email protected]
> > [mailto:[EMAIL PROTECTED] En nombre de Ramiro Diaz
> > Trepat Enviado el: Lunes, 07 de Agosto de 2006 09:27 a.m.
> > Para: [email protected]
> > Asunto: [clubSmalltalk] Re: OmniBase
> >
> >
> > On 8/7/06, GallegO <[EMAIL PROTECTED]> wrote:
> > >
> > > Bruno BB (st) escribió:
> > > > Lo que tenes que tener cuidado es que un ODBMS no es
> una RDBMS, y
> > > > se trabaja de forma diferente.
> > Si, pero el lenguaje de query sigue siendo necesario, al menos algo
> > como el que está proponiendo Magma. En vez de navegar todo
> desde un
> > root Dictionary. Por más que sea un modelo de objetos, siempre que
> > necesites hacer consultas complejas que involucren varios joins de
> > mucho volumen, vas a tener que hacerlas con un lenguaje de consulta
> > (aunque no sea SQL) para que las resuelva el motor de base
> de datos y
> > no las resuelvas vos a nivel de lenguaje con #collect,
> #select, etc.
> > Lo que sería -creo- muy ineficiente.
> > Me alegro de escuchar que OmniBase le anduvo muy bien a
> mucha gente. La
> > última vez que lo probé sobre Squeak/Linux tenía un
> problema de locks
> > que aún no habían resuelto. Pero escuchando todos estos comentarios
> > favorables, voy a volver a probarla.
> > Pero por ahora, me inclino por Magma por que le están dando
> bola a la
> > forma de hacer consultas.
> >
> >
> >
> >
> >
> > >
> >
>
>
--~--~---------~--~----~------------~-------~--~----~
Ha recibido este mensaje porque está 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íe un mensaje a [EMAIL PROTECTED]
Para obtener más opciones, visita este grupo en
http://groups.google.com/group/clubSmalltalk.
-~----------~----~----~----~------~----~------~--~---
