[Seaside] Migrations - Object Database

James Foster Smalltalk at JGFoster.net
Mon Apr 28 18:14:33 UTC 2014


As you say, this isn’t really a GOODS-specific question but a more generic one.

The Programming Guide for GemStone/S 64 Bit has a an entire chapter devoted to the topic (see http://gemtalksystems.com/index.php/community/gss-support/documentation/gs64/). 

There are a variety of approaches to changing the schema of an object. First, since Smalltalk has dynamic typing, you don’t have to have a Profession instance in the profession instance variable of Person. You can store either a Profession instance or a Collection of Profession instances. You can then have accessors that return either one or a collection. Alternatively, in GemStone you can add a method to the old class version to return a collection, and create a new version of the class that stores a collection. Then, at your convenience you can migrate all the instances of the old version to instances of the new version.


On Apr 26, 2014, at 9:55 AM, Aaron Rosenzweig <aaron at chatnbike.com> wrote:

> Hi,
> We’ve been experimenting with GOODS as an object database persistency mechanism for a couple of weeks. We plan to use Dali with it too. We’re really excited about this but have a burning question.
> Question: 
> How do we handle changes to the “model” layer? 
> Example: 
> Suppose that last week we had a “Person” and “Profession” object. Each “Person” could only have one “Profession.” We’ve been saving some data to our Object Database and have 500 people and 25 professions currently saved and used with our app.
> This week we realize that our world view is wrong. Some people are both a “Chef” and a “Computer Scientist.” They have 2 or more professions. We must change our “model.” The class “Person” must change. 
> How do we fix our object database now?
> Background:
> This isn’t really a GOODS specific question is it? I imagine it is the same issue with Magma, GemStone, etc. But in all the examples I’ve found nobody seems to talk about “migrations” or maybe I’ve overlooked it. Can someone point me in the right direction?
> In NeXT / Apple WebObjects I would write a “migration” to do the necessary steps to change SQL tables, make new DB constraints, etc. as an executable script. I would commit this migration to the repository. Any of the other developers on our team would automatically get it when they pulled from the repository. They don’t need to think about it. As soon as the WebObjects app launches the migrations would be run and they could see the new functionality and make “Marcus” both a “Chef and a Computer Scientist." When we deploy the new code in production, the migration will automatically run there too. This is all explained in detail here:
> https://github.com/wocommunity/wonder/blob/master/Frameworks/Core/ERExtensions/Sources/er/extensions/migration/package.html
> Any helpful pointers are appreciated.
> Thank you,
> e:  aaron at chatnbike.com  t:  (301) 956-2319 		
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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

More information about the seaside mailing list