Smalltalk › Frameworks & Tools › Magma

Updating a 'live' environment

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

Amir Ansari

Updating a 'live' environment

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
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/magma

Chris Muller-3

Re: Updating a 'live' environment

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 <[hidden email]> 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
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/magma
>

_______________________________________________
Magma mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/magma

Amir Ansari

Re: Updating a 'live' environment

Thanks, that's exactly what I was looking for! I'm not in that situation, but it's good to know that solutions exist.

Amir

On Wed, 17 Nov 2010 09:48:06 -0600
Chris Muller <[hidden email]> wrote:

> 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

_______________________________________________
Magma mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/magma