Updating a 'live' environment

[Chris Muller]

Hi Amir, for inst-vars of a class persisted in Magma, it just works
like standard Smalltalk, please see:

  http://wiki.squeak.org/squeak/5602

Indexes on MagmaCollections may be removed with the #removeIndex
message (within a commit, of course).

Does this answer your question?

If, by "live" you mean a production environment, then you will want to
practice first on a production copy (you may use #fullBackup to make a
copy of production while it is live without disruption of service).
Adding new indexes to a large collection can take some time, of
course, and the collection cannot be updated while that takes place,
so you may want to build an entirely new MagmaCollection "off to the
side" (but still in the same db) so that, once built, you can "switch
over" to it in a single commit by simply replacing your pointer to the
old with the new..  However, that would require that you keep track of
any updates that came in to the collection being replaced *during* the
index rebuild...

 - Chris


On Wed, Nov 17, 2010 at 12:44 AM, Amir Ansari <fractallyte at csi.com> wrote:
> What is the best practise for updating a 'live' environment?
>
> More specifically: suppose I have a database that is accessed by several instances of an application (say, a load-balanced Seaside app), but need to change the objects comprising the database in any of the following ways:
>
> (1)  Add/remove instance variables to/from a class that is persisted in a MagmaCollection;
> (2)  Add/remove indexes to/from a particular MagmaCollection (perhaps after the changes in (1));
> (3)  Re-factor some of the classes, thus making minor changes to the schema
>
> ... how could the database be updated?  Is there also some way to update all the existing objects in the database to reflect the new changes?
>
> Amir
> _______________________________________________
> Magma mailing list
> Magma at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/magma
>