Emmanuel, Thanks so much for the information. I'm pretty happy with the approach i've got. Take a look if it suits you: https://gist.github.com/1083182
nb., The code in the gist is something I hacked together--it's not specced, and it probably has logical errors. -J. Morris On Jul 14, 2011, at 7:08 AM, Emmanuel Gomez wrote: > Joshua— > > Poor form to reply to oneself, I hear, but I wanted to correct some > misinformation I offered as fact: > > On Jul 13, 2011, at 12:36 PM, Emmanuel Gomez wrote: >> class Unit >> property :id, Serial >> property :type, Class >> has 0..1, :champion >> has 0..1, :structure >> >> def descendant >> case type >> when Champion then self.champion >> when Structure then self.structure >> end >> end >> end > > The case statement in that method won't work (I know better, not sure why I > spouted off with this inaccuracy). Class#=== matches *instances* of a class, > not the class itself. If you are using Ruby 1.9 (or the 'backports' gem), you > could do: > > case type > when Champion.singleton_class then self.champion > when Structure.singleton_class then self.structure > end > > If you are using 1.8.x and one of those gems is not on the menu, then you can > always do: > > case > when Champion == type then self.champion > when Structure == type then self.structure > end > > Hope that saves someone some time. > >> In the event you are querying for a collection of units and their >> descendants, you can do the simpler thing and INNER JOIN Unit with each of >> its descendant tables on :unit_id. If you've successfully preserved the >> uniqueness of a :unit_id among the descendant tables, you will get the >> results you expect. > > This statement is simply untrue. After writing this, I realized that, in the > project I was referring to, I'm 1) not actually using a Class Table > Inheritance hierarchy of the type described (I have multiple 1:m > relationships where the primary key of the target models is a composite > primary key whose components include the primary key of the source model). > And more importantly, I 2) don't deal with a multiple-type query of the kind > requested. > > All is not lost; I have done something similar to what was requested. My > approach issues one query per sub-type and unions the results in Ruby. For a > demonstration of this work-around (I hesitate to call it a solution), please > see: > https://github.com/emmanuel/dm-is-evidence/blob/master/lib/dm-is-evidence/is/evidence/audited/actor.rb#L14-25 > > Apologies for the misinformation, and please let me know if you discover or > devise a more efficient method for instructing DM to issue a query for the > union of multiple-subtypes. Having looked through a bit of the Query code and > inquired with dkubb on the matter, I believe that a multiple-type query is > not possible without fairly invasive changes to DM's query system. > > —Emmanuel > > -- > You received this message because you are subscribed to the Google Groups > "DataMapper" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/datamapper?hl=en. > -- You received this message because you are subscribed to the Google Groups "DataMapper" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/datamapper?hl=en.
