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.

> 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