Persistencia en Squeak

> Una de las cosas que más me joden (y creo que la mayor parte del mundo
> concuerda en esto) es el laburo extra que representa tener que
> persistir los objetos cuando se depende de bases de datos relacionales.
> La solución que propone Smalltalk a la persistencia me parece muy
> copada: todos los objetos son persistentes, y siempre y cuando me
> encargue de grabar la imagen puedo cerrar y volver a abrir teniendo la
> seguridad de que los objetos van a estar ahí cuando vuelva.
> Sin embargo, todavía dependo de las bases de datos cuando la cantidad
> de objetos crece demasiado, porque cargar todo a memoria resulta
> ineficiente.
> Por ahi lo que voy a decir a continuación es una burrada, o alguien lo
> probó y no funcionó, o por ahi existe y yo no lo conozco, pero...
> ¿No estaría bueno un Smalltalk que trabaje directamente con el disco y
> use la memoria Ram como caché?
> De esta forma todos los objetos serían persistentes de forma
> transparente, con la ventaja de poder tener miles o millones de
> objetos en la imagen sin llenar la memoria RAM (¡y adiós a las bases
> de datos! :D).
> Obviamente sería más lento dados los tiempos del disco y de la memoria
> ram, ¿pero si se implementa de la manera correcta no podría tener una
> performance aceptable?
> Digo, se podría trabajar en memoria y periódicamente (cuando impacte
> menos en el rendimiento) un objeto podría volcar ese trabajo en disco
> (tipo el garbage collector pero al reves).
> Asimismo, habría que ampliar el comportamiento del garbage collector
> para que libere espacio en disco y no sólo en Ram.
> O sea, no se cómo hacerlo, pero igual me pareció una buena idea.
>

>
>   La verdad no estaba pensando en ningún proyecto en particular sino en
> aquellos proyectos en que usar sólo la RAM resulta ineficiente (no se
> cuántos objetos son necesarios para que ésto suceda).
> Todo esto viene a mi mente porque encuentro bastante fastidioso tener
> que preocuparme por la persistencia.
> Smalltalk la resuelve de una forma que, a mi gusto, se podría mejorar
> (si bien es más que lo que tengo en otros entornos).
> Por ejemplo: me ha pasado, después de mucho boludear con Squeak,
> terminar con imágenes que superan los 100 mb y se pone engorroso
> correr una imagen de tanto tamaño. Y eso que ni siquiera estaba
> trabajando en algo "pesado", sólo jugando.
> Por eso, para ciertas aplicaciones, se termina necesitando una base de
> datos y pienso que, teniendo un sistema que provee de persistencia
> transparente, no aprovecharlo es un desperdicio.
> Para aprovecharlo hay que hacer algunas modificaciones, yo quería
> saber si alguien las hizo ya y cómo resultaron.
> Si nadie lo hizo todavía (lo cual me parece improbable), entonces creo
> que es algo interesante para discutir.
>
>  
>

>
>
> > A la corta o a la larga todo termina escrito en un disco y de alguna
> forma
> > levantado a RAM.
> >
> > Miraste las bases de objetos, como Magma o esquemas como Prevayler?
> >
> > -gsa.
>
> No entiendo cuál es la ventaja de usar Prevayler en Smalltalk.
> Por lo que estuve leyendo básicamente la idea es mantener todos los
> objetos en RAM y bajarlos a disco periódicamente.
> ¿Cuál es la diferencia entonces con usar una imagen y grabarla
> periódicamente?
> Entiendo que para la gente de Java resulte novedoso porque no trabajan
> basado en una imagen, pero es justamente el esquema del que me quejo:
> me cuesta creer que para proyectos más grandes resulte viable
> mantener toda la info en RAM.
>
>  
>