Hi!
Marco Paga <seaside@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