Hi All,
-- In my domain classes, I have several hierarchies in which I have several instance variables along this hierarchy. Let's assume I want a different table for each concrete subclass (the easiest way I think). In the DescriptorSystem, I have to write the mappings not only for the "state" of the concrete subclass but also from all its superclasses. So superclass state' mapping is duplicated in each subclass.
I understand your reasons of why having the mappings in a separate class rather than in domain classes their-self Still, may be missing something here that could be done using the DescriptorSystem. Thanks in advance, Mariano http://marianopeck.wordpress.com You received this message because you are subscribed to the Google Groups "glorp-group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at http://groups.google.com/group/glorp-group?hl=en. For more options, visit https://groups.google.com/groups/opt_out. |
On 6/7/13 7:04 AM, Mariano Martinez
Peck wrote:
Sometimes you want a different table for each concrete class, but there are situations when you don't. To deal with the situation where you have the same state in several classes because they inherit from a common superclass (or because you have good reason for duplicate state in classes which are not part of the same hierarchy), creating a methods in the DescriptorSystem which define the duplicated state, and calling them from the descriptor, class and table methods which need them. The StoreDescriptorSystem is a good example of a descriptor system built to support an existing database schema *not* built with Glorp in mind. Neither the descriptorSystem nor the schema are perfect, but they are used every day in production Smalltalk shops. Improvements are in the works. Using Glorp to support Store allows us to be Glorp users (and see places for improvement) in the same way you do. A non-trivial Glorp DescriptorSystem definition can be found in the recent releases of VisualWorks (including the currently available Personal Use License version). The class is StoreDescriptorSystem, which has 2 subclasses to represent later versions of the schema. Within that class, here are examples:
In addition, VisualWorks provides the following:
-- You received this message because you are subscribed to the Google Groups "glorp-group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at http://groups.google.com/group/glorp-group?hl=en. For more options, visit https://groups.google.com/groups/opt_out. |
What Tom said. Basically you can split it up into multiple methods and avoid the duplication. It's also possible to have the descriptor methods as class methods on the classes in question, and there are examples of that in the tests. That makes the lack of duplication clearer and probably a little cleaner. Personally, I prefer having them all on the descriptor system, but other people have different tastes.
On 7 June 2013 07:46, Tom Robinson <[hidden email]> wrote:
You received this message because you are subscribed to the Google Groups "glorp-group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at http://groups.google.com/group/glorp-group?hl=en. For more options, visit https://groups.google.com/groups/opt_out. |
Free forum by Nabble | Edit this page |