Magma counseling

goran.krampe at bluefish.se goran.krampe at bluefish.se
Thu Jul 1 06:24:48 UTC 2004


Hi!

Marco Paga <seaside at marco-paga.de> wrote:
> I had problems with Magma too. I switched to goods OO database and it's really 
> working without any problems. You just read some examples and you can start 
> using it.

Nothing wrong with GOODs of course, I played with it a bit and Jonas
here is actually migrating a Hibernate app over to GOODs - will be very
interesting to see the results, especially compared to Hibernate which
people are so excessively worked up about. ;)

But I have also used Magma, and I have had almost no problems.

> Am Mittwoch, 30. Juni 2004 16:53 schrieb Ramiro Diaz Trepat:
> > Does anybody have a more detailed guide or code examples on using Magma
> > than what is on the main Squeak Swiki?

Eh, no. :) But I am making a demo app that uses Magma. Though I am not
sure when it will be ready for "consumption".

> > I am running into problems, at a very eary stage, and I am almost sure
> > that these problems are caused because of my meager knowledge on how to
> > use the framework.
> > For example, all the collections held as attributes by classes that you
> > intend to persist should be MagmaCollections?

No, that is not needed. You can use MagmaCollections if you want the
features they give though. I haven't used them yet.

> > How does the fact of using Magma affect the code and development
> > process?  What are the most important things to keep in mind?

Well, since I haven't done a lot with Magma yet - but I do have some
experience with OOdbs in general. Object migration is likely the most
"tricky" part. Which means the problem of migrating you old objects over
to new evolved classes. I haven't seen exactly what limitations Magma
has in that respect - though I think it can handle some cases.

A general technique that might be useful though is if you have an
import/export format of some kind that will not evolve. One system I
built needed XML import/export for a large sub part of the domain model.
We used that feature to be able to "reload" test data into an empty db
during development.

So in short - having a test db that can be recreated from either
external files of from "instantiation code" can be a real time saver
during development. Then the problem of object migration will not rear
its ugly head until after the first deployment. :)

Note: The above technique is not specific for OOdbs, IMHO it applies
equally well to any system with persistent data.

Finally - the development process with Magma is IMHO more or less like
pretending you are only working in RAM. :) You just sprinkle your
application code (NOT your domain model) with some suitable
begin/commits.

regards, Göran



More information about the Squeak-dev mailing list