question: "Root" explanation

[Chris Muller]

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