[Glass] Class renames and migrations: practices?

[Otto Behrens via Glass]

Hi,

I attach a package with all our migration code if you want to dig.
You're welcome to use it or copy some bits.

> Perhaps there are better ways of handling class renames than what we do? How do other people on the mailinglist handle these?

Not sure if what we do is really better; perhaps we can come up with
something better after some discussion.

> What we do to handle a class rename in a upgrade of our application code:
>
> 1) We keep both the ‘old' class (with the old name) and the ‘new' class (with the new name) in our code base.

We do not keep the old class name in our code base. Essentially we use

Metaclass3 allInstances

to find all the classes in the system and work from there.

> 2) We load the application code upgrade in our database using Metacello and GsDeployer bulkmigrate.

Also load using Metacello, but do not use GsDeployer. We load all the
code first and then do migrations with the attached code. Here's how
we call it:

Migrator new
packageNames: BaselineOfWonkaProjects allPackageNames;
"all our packages / the ones we're interested in migrating"
migrateAll;            "the main entry point"
nilFields.                "To help GC"

> 3) We handle the class rename and migrate all instances as follows:
>
>     SomeOldClass addNewVersion: TheNewClass.
>     SomeOldClass migrateInstancesTo: TheNewClass.

The attached code does this kind of thing automatically if you
implement a hook (class) method:

TheNewClass class >> classNamesToRenameFrom
  ^ #(#SomeOldClass)

You can have multiple old names if you're consolidating more than one
class into a new one

> 4) We remove the old class from the system:
>
>     SomeOldClass removeFromSystem

Have never used this. We have old classes in our systems. Some time
ago, I tried hard to figure out how to get a class garbage collected.
Never could. Perhaps this will work.

We do checks at the end of the migration process that detached classes
should not have instances.

> When we do not do step 4 and we keep SomeOldClass in our code base, subsequent class changes on TheNewClass could trigger the GsDeployer bulk migration to migrate instances of TheNewClass back to SomeOldClass before migrating to the last version of TheNewClass. When we inspect the classHistory of both classes, we notice they are shared and can look like this: SomeOldClass -> TheNewClass -> SomeOldClass -> TheNewClass -> SomeOldClass. It all depends on the changes to SomeOldClass and TheNewClass, package load order, etc… wether or not this would eventually end up in a good state (but most probably not). So, we avoid this issue by explicitly removing the class now in step 4.

We are a bit more pedantic about cleaning up the classHistory (see
tearDownClassHistoryForMigratingFromClass:). After a migration run,
all classes should have only itself in its own classHistory.

>
> So, we only figured this out because we had not done step 4 in migrations in early years and we kept the old classes for ‘legacy’ in our code base. The main question is: is this a good way to deal with class renames in application upgrades?

Our way of working is to remove the legacy class from the code base asap

HTH
Otto
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Wonka-Migrations-Core-otto.1235.mcz
Type: application/octet-stream
Size: 10049 bytes
Desc: not available
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20160427/37594333/attachment.obj>