[Seaside] Migrations - Object Database

[Chris Muller]

Hi,

...
>

> 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?
>

Sure, sometimes migration can require to successive repairs.  The first to
add the new ivar / relationship, the second to remove the old one.

In fact, sometimes there's no big hurry to remove the old one.  The old
ivars can remain for one release of your app or so, and then, upon the next
release, remove it.


> 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?
>

Nothing wrong with this if it suits the situation.  My only comment is that
I don't particuarly like to put commits into lazy-initializing accessors.
 And, so, my Person objects would be "healing" themselves on every access
from a new session.  Plus, the DB would be only partially migrated, which
can lead to a mess if, subsequently, you want to do yet _another_ migration
along the same ivars (e.g., you now have two possible input states instead
of just one, which makes getting to 3rd state more difficult).


>
> 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.
>

Well, I don't actually define my Repairs in workspaces but as class-side
methods of the root object of the DB, where they remain for at least a few
versions.

I assume your app has a bootstrap / initialization and so you could
certainly invoke the repair at that time.  Repair failure would be treated
just like a regular Error which I assume would cause the app bootstrap
process to abort accordingly..


> 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?
>

Right now, multiple successive Repairs are left to the app-developers.
 Certainly, a SequenceableCollection of DataRepairs could be applied in
sequence to your data-model, where each Repair is designated to be applied
only to a particular #version of your apps data-model, so that earlier ones
would be skipped if they were no longer necessary.

But Magma doesn't know what the individual app's version naming / numbering
scheme is, and so this is currently left to the app-developers to handle
themselves.

  - Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/magma/attachments/20140427/cc2f517c/attachment.htm