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
|