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