About GemStone (was Re: Proposal for the coming versions)

Michael Roberts mike at mjr104.co.uk
Wed Mar 15 00:56:26 UTC 2006


Daniel said
"...just wanted to remind ourselves that systematic treatment of live 
system updates is possible at least in the sense that GemStone does it. "

Cees de Groot wrote:

> Could you explain a bit about the Gemstone model you are referring to?
> I only have marginal GS exposure, and I'm sure that I'm not the only
> one.

I certainly don't want to talk on Daniel's behalf... but I have some 
exposure to GS and can maybe suggest a few things of interest. 
Apologies if this is off-topic, way off, etc...

One thing that GemStone provides is a concept of 'class version'.  This 
is separate from the concept of 'class'.

If we think about the operation of a Smalltalk environment we have quite 
a simple view of the changing of the shape of a class.

Say we have a class User, with an instance variable firstName.  Say we 
make a few users:
	#(fred wilma barney betty) collect: [:each |
		User named: each]

Now we have 4 instances of User.  Say we now add another instance 
variable to User, familyName.  By adding this new instance variable we 
change the shape of the class and on our behalf all existing instances 
are populated with the new variable familyName, referencing nil.  We can 
go on to make more Users and provide the existing instances with 
suitable values for familyName if we wish.

I say simple 'view' above because it's not necessarily a simple 
operation.  We do, however, just watch it happen.

So on the concept of class version in our image, we can define the 
shapes A and B of User, and observe the transition from A to B but we 
have all our instances moved from A to B.  This is after all a very 
convenient feature of our environment...

In GemStone we can create a similar class User, with the same initial 
instance variable firstName, and make the same four instances.  If we 
commit these changes within a transaction we make them available to all 
users of the database.

We can now add the second instance variable to our GS class.  At this 
point GemStone provides us with this additional concept of class 
version.  By adding the second instance variable we alter the creation 
of *new* instances of User.  So we can make
	User firstName: #pebbles familyName: #flintstone

We do not, however, force this shape change onto existing GS instances 
of User.  This is because the original User class object is still 
available and providing the class of the original four instances.  So 
you have the following situation in a pseudo fashion:

User[1]
	instanceVariableNames: 'firstName '

inspecting User[1] allInstances --> (an array of size 4, fred wilma...)

User[2]
	instanceVariableNames: 'firstName lastName '

inspecting User[2] allInstances --> (an array of size 1, pebbles...)

In the GemStone class browser you can view these two distinct versions 
of User [1] and [2].

You can then GS evaluate
	User classHistory

which answers a class history object (basically an array) containing the 
two versions of the class, which are respectively the first and second 
class objects we made.

What you can then do is migrate all the instances of the first class 
version to instances of the second class version. You can do this at any 
point you decide as long as you have class versions to migrate to. You 
can then hook into this migration to perform any necessary upgrade steps.

So GemStone provides the ability to have a number of versions of a 
class, and all associated instances, all running in the same DB, at the 
same time.  It would be an understatement to say it's cool...

Of course, I've only talked about state.  As classes reference the 
method dictionaries that define their instances' behaviour these are 
also versioned by the same process.  You can evolve the state and 
behaviour of your classes and keep older instances around that still 
behave 'correctly'.  It is up to you to define what correctly means 
because you have to decide what protocol the clients of your objects 
expect in the presence of different instances of different versions of 
the class.

 From the point of view of updating a live object system - we started 
off there didn't we! - the ability to do any of this at all, and within 
a transaction is particularly powerful; not least because you can abort. 
  You can try out the migration, and even do unit tests, but not 
actually commit the changes.

Cheers,

Mike



More information about the Squeak-dev mailing list