Squeak
  links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
Live Class Evolution in Magma
Last updated at 7:00 am UTC on 29 March 2018

Overview

Magma and Monticello can serve as a basis for a distributed team of developers in different geographic locations to collaborate on both the objects and code of a domain model. Developers may remain connected to the repository during development, as class evolution occurs, and Magma will try to "do the right thing" within the scope of each connected image.

Principles

Every Magma database has a special area allocated to store the Monticello code packages used to run the #root object model.
This code repository can be used as a distributed developer code repository based on the following principles:

[*] The one exception is if the class-type changes; e.g., Pointers vs Bytes vs Words. This is not supported.

Class Evolution

As distributed developers connected to the same repository commit instances, Magma will map the variables by name. Classes may be renamed and Magma will detect the existing instances are instances of the newly named class, even in your co-developers images who haven't renamed that class.

Instance-variable renames are not tracked; for now you have to deal with this manually.

If Developer1 adds an instance variable and commits references to it, other developers may still read that object, but if the version of the same class in their image does not have the newly-added variable, any commits they do to that object may cause that variable to be reset back to nil. Typically, new variables are only added in "development" where coordination with other developers is common anyway.

Implementation

Magma keeps a collection of MaClassDefinitions, an object which describes the particular state of a class at a particular time, in its repository definition.

When an object is read, Magma will map the instance-variables by name to whatever class has the same name. This is the way Smalltalk has always handled this. If a class with that name doesn't exist in the image, it compiles one according to the MaClassDefinition for that object.

Magma does keep track when classes are renamed. If a class is renamed, Magma will know to map old instances to the newly named class.

Currently, renaming an instance variable is seen as a new variable and not automatically transferred.

Upgrade strategies

As in any database, two common strategies for "upgrading" old-version objects to a newer version are: