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@lists.squeakfoundation.org [mailto:squeak-dev-bounces@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
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@lists.squeakfoundation.org [mailto:squeak-dev-bounces@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@lists.squeakfoundation.org [mailto:squeak-dev-bounces@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
squeak-dev@lists.squeakfoundation.org