Hi Ian,
I am interested to convert my existing application from Oracle to Magma simply due to simplicity to manage and get away from converting from data to object and back, plus other issues involving relational database management.
Cool. That's exactly what Magma is for. Welcome.
Anyway I do code in Smalltalk, but new to Squeak and definitely have no experience in Object databases. I read the literature and reviewed the Magma-Tester... classes to help me to understand the concept and the usage.
One of the recommendations remains unclear, that is - NOT to use the Dictionary class as the ROOT, but instead use some other class to avoid the depth of "1", which is common for Collection classes retrieval.
Could you please elaborate, what would you use for the superclass of the root class and would it have any subclasses (if any, please provide example). The point of confusion is that the method at:put: would be implemented in the root class and it is implemented in some of the collection classes. The Object class (which is one of of implementers) expecting integers only and I would like to have literals such as "person". The collection classes would allow for literals, but the recommendation (my assumption) would be other than the collection class.
Obviously, I am missing something, please provide some examples (or correct me) so it would help me to move forward in the way that you have intended.
The root can be any object whose class directly or indirectly inherits from Object. #at:put: is just a message selector, it has nothing to do with the root of the database.
Every Magma database is basically "one big object", the root object. Only what is reachable from that root is regarded as part of the database.
For doing simple tests and playing around with Magma, a Dictionary is fine to have as the root. But for all of my real applications, I prefer to have a first-class root object which represents the entirety of that domain model. Even large domain models which are made up of several distinct groups of classes. For example, in a bookkeeping application, you could make your root object be a AccountingBook, which would have inst-vars, 'accounts contacts transactions'. I find this to be much more preferable than to have a Dictionary with 3 keys, 'accounts', 'transactions' and 'contacts' because you can delegate application behaviors to AccountingBook, and since you never have to worry about adding or removing instVars either, a Dictionary provides no advantage.
- Chris