Quantcast

question: "Root" explanation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

question: "Root" explanation

magmaodb dslextreme.com
Hello,
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.

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.

Ian


_______________________________________________
Magma mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/magma
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: question: "Root" explanation

Chris Muller-3
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
_______________________________________________
Magma mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/magma
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: question: "Root" explanation

magmaodb dslextreme.com
Good Morning Chris,

I just wanted to thank you for the response and explaining what Magma is and how it works. I was experimenting with it for a past few days. In your example below the instance variables on the root object would each contain the Magma Collections, where objects can be manipulated. I noticed that internally you create MaIdentityDictionary and add objects as keys and associate with OrderedCollection. I did not experiment enough to see what these collections (OrderedCollection) are used for yet. I also noticed that these object (keys) are easily convertible to Array of objects, pretty convenient. This product is full of interesting features and therefore possibilities.

Magma will work well for my application, it allows plenty of flexibility in a way it fits into the application with hardly any restrictions typical in Relational and Hierarchical databases. Strangely enough I could store non heterogeneous objects in the same collection, I can't think of the reason to do it, but it may be done, allows additional flexibility if needed.

The queries (Reader class) are of particular interest (need to experiment more on that, just started), because users always are interested in retrieving data in variety of ways and your implementations makes my job simpler.

One of the surprising and welcoming features is that it feels you are still coding in Smalltalk (because it is) as you work with the Database and that allows better integration and simpler maintenance, it is all one environment. There are still plenty of opportunity for the novice to get lost and room for confusion, but the fact that the system is written in Smalltalk and open source allows one to review the appropriate classes and experiment.

This is good product and a thoughtful design. You deserve all the accolades you are receiving. Thank you for making this product available and for your support.

As I am gaining more experience and dig dipper, I am sure I will have more questions, but now I know I can rely on your responses and that is what counts when it comes to support, not the quantity of people you can ask questions, but the quality of support even if you are one person.

Ian

----- Original Message -----
From: "Chris Muller" <[hidden email]>
To: "magmaodb dslextreme.com" <[hidden email]>
Cc: "magma" <[hidden email]>
Sent: Sunday, July 26, 2015 2:53:08 PM
Subject: Re: question: "Root" explanation

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

_______________________________________________
Magma mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/magma
Loading...