Andrew Sullivan wrote:
> On Mon, May 31, 2010 at 03:25:24PM +0200, Lorenzo Bolzani wrote:
>> So this could be an actual scenario:
>>
>> master:  version 1.34
>> slave1:  version  1.35
>> slave2:  version  1.32
>>
>> Any version update could imply some schema changes, for example:
>>
>> - add/drop/modify a column
>> - add/drop a table
> 
> You're not going to be able to do this without a lot of pain.
> 
> However, one way you could maybe do it is with quite complicated
> views.  I think this would be more painful than it would be worth, but
> I investigated the feasibility of this for someone one time, and it
> was just possible.
> 

Techniques along these lines are described in Scott Ambler's 'Database 
Refactoring' book 
(http://www.amazon.com/Refactoring-Databases-Evolutionary-Database-Design/dp/0321293533/ref=sr_1_1?ie=UTF8&s=books&qid=1275320926&sr=8-1)

The idea is that you use a mixture of views and triggers to have 1 
schema that can be used by both versions of the applications that expect 
different schemas.  You then upgrade all your applications and then you 
swap the schema out to one that only has support for the newer version 
of the application.

This sounds like a lot of extra work




> A
> 
> 
> 


-- 
Steve Singer
Afilias Canada
Data Services Developer
416-673-1142