[Glass] Class Migration

[Martin McClure via Glass]

On 02/01/2016 08:36 PM, Otto Behrens wrote:
> Thanks, that's interesting.
>
>> If you have the flexibility to take the site down while migrating, that
>> is easier. For applications that cannot incur the downtime, migration is
>> usually a two-phase process.
>
> Fortunately, we've always had a window to take the site down.
>
>> In a two-phase application update, the first phase modifies the
>> structure of the objects, but leaves the behavior the same. This allows
>> the system to behave predictably when some objects are migrated and
>> others are not.
>
> Your code cannot be totally ignorant of new structures, so perhaps
> you'll have to write some code that can handle both old and new
> structures? But you can do that in one commit though.

The old class version and the new class version are different classes, 
and so can have different code. The important thing is to make the 
external behavior the same in the first phase, even though the structure 
is different.

>
>> Once all objects have their structure migrated, a second
>> software update with no structural changes brings in the behavior that
>> needed the structural change. The second phase can be done as a single
>> commit, so the cutover to the new application version is essentially all
>> at once.
>
> A seaside application using stuff like "commitWhenAlmostOutOfMemory"
> would certainly not work then.

You update the code with a single commit. Each production gem then sees 
that change at its individual next transaction boundary. Because it's 
all transactional, no gem can see changes committed by a gem that's 
using the new code until it is also using the new code.

You can have a gem that's using old code commit (once) after some other 
gem(s) have committed using new code, but the normal prevention of 
commit conflicts is usually enough to prevent this from being a problem.

>
>> This takes more careful coding and is more work, but it does enable 24/7
>> uptime applications to evolve.
>
> I can imagine! A bit more careful planning too.

Indeed. You have to think through your changes, and what the 
transitional states will be.

Regards,

-Martin