[Seaside] datasets and modes..

[Dale Henrichs]

----- "Philippe Marschall" <philippe.marschall at gmail.com> wrote:

| 2008/10/22 sergio <sergio at village-buzz.com>:
| >
| > in developing rails (for example) i have a data set that i use for
| > development..
| >
| > i make changes (migrations) against the current codebase.. then,
| when
| > everything works, i submit it (svn)..
| >
| > on the server side..
| >
| > i update (svn..) migrate.. then restart..
| >
| > how does this work with seaside?
| >
| > do i have two datasets (production and development)?
| >
| > how do i maintain the integrity of my data when i make drastic
| changes to
| > the code on the development side?
| 
| Seaside is just a web framework. It does not do any persistence at
| all. So this entirely depends on what you use for persistence.
| 

With Smalltalk (your Squeak image), you get image-based persistence ... As you modify your classes, the system 'migrates' the instances of the class automatically, when you 'save your image' you have persisted the code changes and the migrated objects.

GemStone/S (GLASS) gives you an OODB that uses a model that is virtually identical to the 'standard' Smalltalk persistence. In GemStone, instead of saving your image, you do a 'commit'. By default, GLASS automatically migrates the instances in your data base (like in your Squeak image. GemStone/S allows you to customize your migration strategies or even choose to not migrate instances at all...

It is a good idea to keep your production and development separate, so with the Smalltalk model, you can modify classes and 'automatically' migrate your instances in the development image, then when you load the final set of proudction-ready code into your production Squeak image, you production instances will be automatically migrated.

The same thing goes for GemStone and GLASS.

Someone else will have to tell you how migration works for GLORP, I assume that GLORP will have similar capabilities...

Dale