[Seaside] Migrations - Object Database

[Diego Lont]

Hi Aaron,

To avoid migration trouble I usually use lazy initialisers, accessing them as properties. With other words: I keep my initialize method as empty as possible. And when I have a “migrated” value, then I try to come up with a new name and put the migration code in the initialiser. When this initialisation becomes complex I have the following pattern:

x
	^x ifNil: [ x := self buildX ]

buildX
	| newX |
	“ do the complex initialisation “
	^newX

I do not know if this can be easily applied to databases as well (I myself use pharo / gemstone), and I still have moments where something goes wrong because the data is not migrated properly, because I forgot something, but it saves a most of trouble.

Diego

> Hi Chris,
> 
> You don’t just use Magma, you *are* Magma! Thank you for the thoughtful reply. That does look like a great feature of Magma but it leads me to four questions:
> 
> 1) Old vs. New?
> As you instruct MagmaDataRepair to enumerate and “hydrate” your objects from the DB, how do you look at the “old way” and the “new way” at the same time so you can do the #improve message? In my example the old way had a Person -> Profession (a to-one relationship, a single object). In the new way Person ->> Profession (a to-many relationship, an array, or B-Tree, etc). The class in Smalltalk is already “new” so how can it deal with the “old” form of what was stored in the DB?
> 
> 2) Lazy Improve
> What if the object itself, “Person” could know how to improve itself? And as you access Persons they automatically improve themselves. Then you wouldn’t need to modify all the objects at once and they could self-heal as needed. It would need a way to look at its old self and “self improve.” Is this a bad idea? Anyone done this?

> 
> 3) Auto repair / improve
> It looks like MagmaDataRepair is something I would run from a workspace. Suppose I was working on this app with Dirk and Dave. Do I really have to tell them both “Hey guys, I’m going to Skype you some text to run in our workspace to update our data model but before you do, pull from the repo.” That seems like a lot to remember and go wrong. Isn’t there a way after the pull from the repo and accessing your app that it will “self improve” so I don’t actually have to tell Dirk and Dave anything and when we deploy we don’t have to remember to do anything either.
> 
> 4) Queued repairs / improvements
> Imagine one of my team-mates was on vacation for two weeks. After he comes back he wants to get back into our Smalltalk app. During that time there have been 7 (seven) MagmaDataRepair scripts created by various people (Me and Dirk mostly). Isn’t there a way to have them all put together in chronological order so when Dave returns from his cruise he can just “run” and all 7 MagmaDataRepairs will be applied without him thinking about it?
> 
> Thanks,
> AARON ROSENZWEIG / Chat 'n Bike
> e:  aaron at chatnbike.com  t:  (301) 956-2319 		
> 	
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20140428/e6db620e/attachment.htm