Yeah Kevin sure I can. I don't know if you're familiar to the way in which
the VM stores the objects  in RAM. It does that in a sort of table. So I
thought that maybe I can apply the same idea to another than the RAM. That
medium can be a RDBMS. 

The key is to forget completely about mapping. To forget thinking in
relationalish. And to be able to gain the industry proved value of RDBMS's
without having to think in relationalish.

The use of relational algebra and SQL is trivial, the system have (right
now) 3 tables 
	1. object
	2. root
	3. symbol
The object table is in fact that: the table that stores objects (one row per
instance).
The root and symbol tables are complementary. Symbol is a table that acts as
dictionary to translate the object pointers of the classes to readable
classes names. Root has 1 row and allows you to solve a kind of chicken-egg
kind of problem.

The rests is in the table object. It's fields are:

	1. objectId. Longint. The object pointer instead of RAM in the DB
	2. generation. Int. (not in use right now, needed by a generational
GC)
	3. marked. Boolean. (not in use right now, needed by a GC)
	4. referenceCount. Bigint. Also for GC
	5. isFinalizable. Boolean. To now if should send a message #finalize
previus GC
	6. isImmutable. Boolean. To make possible add security, etc.
	7. classPointer. Bigint. The value of objectId that is the class of
this instance.
	8. classType. Text. The kind of class (normal, variable, bytes, etc)
	9. slot. Bytearray. The blob that has serialized the instvars values
os this instance

	That is the basic support. I've stored an image segment of ~180KB in
~6900 rows of this table. The rest is done by the system. I should have a
look at it to remember better. The deserialization depends on the kind of
class. I've used 1 tagged integers I think (I remember not to change
squeak's design for that).

	Several tests where passing green. 

	This has no one optimization, but I think that glorp is caching
something behind the scenes. I've read that write an read barriers are used
to optimize this kind of approaches. Also has no garbage collection yet
which is not a short run kind of problem because you have the whole disk
instead of RAM.

	I also thought about being possible to take advantage of RDBMS's
triggers mechanism to make objects in the disk to send messages to any other
object allowing to implement events in persisted objects (I think this is
called active persistance).

	cheers,

Sebastian Sastre
PS: I can share the development if there is interest on this

 

> -----Mensaje original-----
> De: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] En 
> nombre de Kevin Driedger
> Enviado el: Jueves, 30 de Agosto de 2007 16:48
> Para: The general-purpose Squeak developers list
> Asunto: Re: pipe (scaling image)
> 
> Sebastian, this is a neat idea could you give just a little 
> bit more detail on how the objects are mapped into the SQL 
> database?  I can only guess that you mean that they are 
> somehow chunked  into blobs and persisted.
> 
> ]{evin
> >
> > Sebastian Sastre wrote:
> >> But an image can be scaled in a farm of servers. A persistent 
> >> Smalltalk can have valuable objects transparently stored in a 
> >> shareable support.
> >> I've implemented in Squeak a *proof of concept* of this idea in a 
> >> system that can store in a relational database the objects without 
> >> having to map classes to tables. It uses the same 
> intention that the 
> >> VM uses to store objects in RAM. It uses the RDBMS as if 
> it where an 
> >> analogy of the RAM. I based the design on the blue book. 
> The idea is 
> >> not original Sun has played with something like this for Java.
> >>
> >> Every instar value you change in an object is made ACIDly. Is slow 
> >> because the support is slow. Write and read barriers can 
> help a lot. 
> >> Concurrency also should be managed.
> >>
> >> But you can make a really big image with this by scaling 
> it as much 
> >> as PostgreSQL can scale.
> >>
> >> Cheers,
> >>
> >> Sebastian Sastre
> >>
> >>
> >>  
> >>> -----Mensaje original-----
> >>> De: squeak-dev-bounces at lists.squeakfoundation.org
> >>> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] En 
> nombre de 
> >>> Marcel Weiher Enviado el: Miércoles, 29 de Agosto de 2007 20:51
> >>> Para: The general-purpose Squeak developers list
> >>> Asunto: Re: pipe
> >>>
> >>>
> >>> On Aug 26, 2007, at 3:10 AM, Fabio Filasieno wrote:
> >>>
> >>>    
> >>>>> Smalltalk is very different - you always can add 
> behaviour         
> >>> you need    
> >>>>> to the other object and the application logic is         
> >>> distributed across    
> >>>>> the system.
> >>>>>         
> >>>> That's not the point, but you are right, Unix and Smalltalk are 
> >>>> different.
> >>>> In regard to the black boxes thing.
> >>>>       
> >>> I think a lot of the differences are superficial, but one 
> seems very
> >>> deep:  Unix's unifying principle is extensional, 
> Smalltalk intensional.
> >>>
> >>> That is, Unix gets its power from the fact that 
> everything is just 
> >>> represented as bytes, and you can pipe those around.  Who 
> cares what 
> >>> they mean?  To the refined tastes of us Smalltalkers that seems 
> >>> barbaric, but it is very powerful in a very pragmatic 
> sort of way, 
> >>> and gets you extremely loose coupling and late binding (of things 
> >>> other than the fact that it's all just bytes).  Of 
> course, you lose 
> >>> moving to higher levels of abstraction, and no, XML 
> doesn't really 
> >>> do it.
> >>>
> >>> Smalltalk, on the other hand, does really well with modelling 
> >>> semantics, as objects sending messages, but has a hard time 
> >>> extending its unifying principle outside the image.  Which is 
> >>> somewhat ironic considering the idea was connecting 
> things and late, 
> >>> late binding.
> >>>
> >>> Marcel
> >>>
> >>>
> >>>     
> >>
> >>
> >>
> >>   
> >
> >
> 
>