i love rails but this single page make me think that the STI choice leads to weird things ... oop with ruby is beauty and sti breaks this beauty... http://developer.apple.com/documentation/WebObjects/UsingEOModeler/ 7ModelingInheritance/chapter_7_section_2.html#//apple_ref/doc/uid/ TP30001018-DontLinkChapterID_6-CACFDHEB
In object-oriented programming, when a subclass inherits from a superclass, the instantiation of the subclass implies that all the superclass’ data is available for use by the subclass. When you instantiate objects of a subclass from database data, all the database tables that contain the data held in each class (whether subclass or superclass) must be accessed so that the data can be retrieved and put in the appropriate enterprise objects. I want that approach with active record :) this is a must have for rails 1.0 no ? On 16 juin 05, at 20:17, olivier hericord wrote:> i love rails but this single page make me think that the STI choice > leads to weird things ... oop with ruby is beauty and sti breaks > this beauty... > > http://developer.apple.com/documentation/WebObjects/UsingEOModeler/ > 7ModelingInheritance/chapter_7_section_2.html#//apple_ref/doc/uid/ > TP30001018-DontLinkChapterID_6-CACFDHEB > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On Jun 16, 2005, at 2:20 PM, olivier hericord wrote:> In object-oriented programming, when a subclass inherits from a > superclass, the instantiation of the subclass implies that all the > superclass’ data is available for use by the subclass. When you > instantiate objects of a subclass from database data, all the database > tables that contain the data held in each class (whether subclass or > superclass) must be accessed so that the data can be retrieved and put > in the appropriate enterprise objects. > > I want that approach with active record :) this is a must have for > rails 1.0 no ? >If you do not include a column named "type" AR will use the inheritance you''re used to and not STI. See the STI section of the AR API docs at http://rails.rubyonrails.com/classes/ActiveRecord/Base.html -Scott _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Scott Barron wrote:> > On Jun 16, 2005, at 2:20 PM, olivier hericord wrote: > >> In object-oriented programming, when a subclass inherits from a >> superclass, the instantiation of the subclass implies that all the >> superclass’ data is available for use by the subclass. When you >> instantiate objects of a subclass from database data, all the >> database tables that contain the data held in each class (whether >> subclass or superclass) must be accessed so that the data can be >> retrieved and put in the appropriate enterprise objects. >> >> I want that approach with active record :) this is a must have for >> rails 1.0 no ? >> > > If you do not include a column named "type" AR will use the > inheritance you''re used to and not STI. See the STI section of the AR > API docs at http://rails.rubyonrails.com/classes/ActiveRecord/Base.html >I think he wants to be able to do something like Customer is a Person and have customer and person tables both pulled from properly which rails doesn''t do... or am i missing something here? _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On Jun 16, 2005, at 2:59 PM, Sean T Allen wrote:> > Scott Barron wrote: > >> >> On Jun 16, 2005, at 2:20 PM, olivier hericord wrote: >> >>> In object-oriented programming, when a subclass inherits from a >>> superclass, the instantiation of the subclass implies that all the >>> superclass’ data is available for use by the subclass. When you >>> instantiate objects of a subclass from database data, all the >>> database tables that contain the data held in each class (whether >>> subclass or superclass) must be accessed so that the data can be >>> retrieved and put in the appropriate enterprise objects. >>> >>> I want that approach with active record :) this is a must have for >>> rails 1.0 no ? >>> >> >> If you do not include a column named "type" AR will use the >> inheritance you''re used to and not STI. See the STI section of the >> AR API docs at >> http://rails.rubyonrails.com/classes/ActiveRecord/Base.html >> > > I think he wants to be able to do something like > > Customer is a Person > > and have customer and person tables both pulled from properly which > rails doesn''t do... > > or am i missing something here? >Ah, perhaps I misread what he was asking then. -Scott _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On 16 juin 05, at 20:59, Sean T Allen wrote:> > Scott Barron wrote: > > >> >> On Jun 16, 2005, at 2:20 PM, olivier hericord wrote: >> >> >>> In object-oriented programming, when a subclass inherits from a >>> superclass, the instantiation of the subclass implies that all >>> the superclass’ data is available for use by the subclass. When >>> you instantiate objects of a subclass from database data, all the >>> database tables that contain the data held in each class (whether >>> subclass or superclass) must be accessed so that the data can be >>> retrieved and put in the appropriate enterprise objects. >>> >>> I want that approach with active record :) this is a must have >>> for rails 1.0 no ? >>> >>> >> >> If you do not include a column named "type" AR will use the >> inheritance you''re used to and not STI. See the STI section of >> the AR API docs at http://rails.rubyonrails.com/classes/ >> ActiveRecord/Base.html >> >> > > I think he wants to be able to do something like > > Customer is a Person > > and have customer and person tables both pulled from properly which > rails doesn''t do...exactly !!!! :) i find this AN ENORMOUS limitation of active record and i want to know if it''s planned to make this aspect of AR change...> > or am i missing something here? > > > <sean.vcf> > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
> exactly !!!! :) > > i find this AN ENORMOUS limitation of active record and i want to > know if it''s planned to make this aspect of AR change... >While I''m not sure if it''s on the roadmap - I can be 1000% sure that if you took the time to fix the bug you want fixed - that it would be more then happily looked at for inclusion just as soon as you finished.... John W Higgins wishdev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
On Jun 16, 2005, at 1:55 PM, olivier hericord wrote:> On 16 juin 05, at 20:59, Sean T Allen wrote: >> I think he wants to be able to do something like >> >> Customer is a Person >> >> and have customer and person tables both pulled from properly >> which rails doesn''t do... > > exactly !!!! :) > > i find this AN ENORMOUS limitation of active record and i want to > know if it''s planned to make this aspect of AR change...What does it limit? I think in a study of inheritance mapping strategies you will find that single-table inheritance is typically the most attractive. Class-table "makes sense" but is not particularly sensible. Best, jeremy
On 16 juin 05, at 23:09, John W Higgins wrote:>> exactly !!!! :) >> >> i find this AN ENORMOUS limitation of active record and i want to >> know if it''s planned to make this aspect of AR change... >> >> > > While I''m not sure if it''s on the roadmap - I can be 1000% sure > that if > you took the time to fix the bug you want fixed - that it would be > more > then happily looked at for inclusion just as soon as you finished....unfortunately my skills with ruby doesn''t allow it yet....and more than a bug fix it''s a question about ActiveRecord future ....> > John W Higgins > wishdev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On 16 juin 05, at 23:14, Jeremy Kemper wrote:> On Jun 16, 2005, at 1:55 PM, olivier hericord wrote: > >> On 16 juin 05, at 20:59, Sean T Allen wrote: >> >>> I think he wants to be able to do something like >>> >>> Customer is a Person >>> >>> and have customer and person tables both pulled from properly >>> which rails doesn''t do... >>> >> >> exactly !!!! :) >> >> i find this AN ENORMOUS limitation of active record and i want to >> know if it''s planned to make this aspect of AR change... >> > > What does it limit? I think in a study of inheritance mapping > strategies you will find that single-table inheritance is typically > the most attractive. Class-table "makes sense" but is not > particularly sensible.i want to be abble to find a user by its name even if the name field is in the contacts table.... we should be abble to write user.name....no?> > Best, > jeremy > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
> > What does it limit? I think in a study of inheritance mapping > > strategies you will find that single-table inheritance is typically > > the most attractive. Class-table "makes sense" but is not > > particularly sensible. > > i want to be abble to find a user by its name even if the name field > is in the contacts table.... we should be abble to write > user.name....no?You can always create a name() method in your User model: def name self.contact.name end Obviously, this doesn''t solve the inheritance deficiency, but it will allow you work as if it is, and then if/when this support is added, all you have to do is delete name().
On Thu, 16 Jun 2005, olivier hericord wrote:> i want to be abble to find a user by its name even if the name field is > in the contacts table.... we should be abble to write user.name....no?No. But you can add a method into your model file that will find whichever and return that. I don''t have a ruby install on the machine I''m working at (and I''m a newbie) so I can''t test this, but something like: def self.username if name = "" contact.contact_name else name end end -- _Deirdre web: http://deirdre.net blog: http://deirdre.org/blog/ yarn: http://fuzzyorange.com cat''s blog: http://fuzzyorange.com/vsd/ "Memes are a hoax! Pass it on!"
John W Higgins wrote:>>exactly !!!! :) >> >>i find this AN ENORMOUS limitation of active record and i want to >>know if it''s planned to make this aspect of AR change... >> >> >> > >While I''m not sure if it''s on the roadmap - I can be 1000% sure that if >you took the time to fix the bug you want fixed - that it would be more >then happily looked at for inclusion just as soon as you finished.... > >Its on my personal list of things to do when I have time... unless ( and this would make me happier )... someone else beat me to it. But yeah I suspect a lot of folks would want this... _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
> You can always create a name() method in your User model: > > def name > self.contact.name > end > > Obviously, this doesn''t solve the inheritance deficiency, but it will > allow you work as if it is, and then if/when this support is added, > all you have to do is delete name()a very pragmatic answer but that''s against the first rule....DRY :)
i asked david in private about that. his answer: "I don''t miss it at all. So I personally, I have no burning desire to get it in. It''ll get in if someone wants it bad enough to actually put in the work to do it." again a very pragmatic answer :) i just ask for one thing "being convinced that CTI is useless in Rails".... how do you solve the common problem of ''users'', ''players'', ''visitors'' all pointing to a contact table? how can you find a user by name for instance when name is a contact attribute ?
olivier hericord wrote:> i just ask for one thing "being convinced that CTI is useless in > Rails".... how do you solve the common problem of ''users'', > ''players'', ''visitors'' all pointing to a contact table? how can you > find a user by name for instance when name is a contact attribute ? >set_table_name "contact" breaks doing an :include => [:players, :visitor] since tables arn''t aliased during eager joins, but if they were doing conditions => [''joined_table.column = ?'', @some.thing] would get confusing awfully quickly (since you wouldnt know the alias). -Matt Beale
On 6/17/05, olivier hericord <hangonsoft-GANU6spQydw@public.gmane.org> wrote:> > I think he wants to be able to do something like > > > > Customer is a Person > > > > and have customer and person tables both pulled from properly which > > rails doesn''t do... > > exactly !!!! :)I don''t want to be too much of a curmudgeon. But Customer is a person is, *literally*, a textbook case of abusing inheritance. Continuing this approach What about staff members? They''re Persons too? Staff is a Person? Then what about Staff members who are Customers? StaffCustomer < Staff, Customer? Then what about Customers who used to be Staff members? You have to take a StaffCustomer (which isn''t possible in ruby) and transmogrify it into a Customer. Also not possible in ruby. What you''re after is: Customer belongs to Person Staff belongs to Person And yes, that means you can''t go user.name,> i find this AN ENORMOUS limitation of active record and i want to > know if it''s planned to make this aspect of AR change... > > > > > or am i missing something here? > > > > > > <sean.vcf> > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Cheers Koz
On Jun 16, 2005, at 2:31 PM, olivier hericord wrote:> i just ask for one thing "being convinced that CTI is useless in > Rails".... how do you solve the common problem of ''users'', > ''players'', ''visitors'' all pointing to a contact table? how can you > find a user by name for instance when name is a contact attribute ?In this case has-a better reflects Ruby OO than is-a, which begs for multiple inheritance. Class-table inheritance is not useless in Rails; rather, single-table inheritance is simpler and more often effective. It isn''t unwanted but won''t be added just for completeness'' sake. Patches are welcome, though I fear that its implementation will lead to its frequent misapplication. jeremy
Michael Koziarski wrote:>On 6/17/05, olivier hericord <hangonsoft-GANU6spQydw@public.gmane.org> wrote: > > >>>I think he wants to be able to do something like >>> >>>Customer is a Person >>> >>>and have customer and person tables both pulled from properly which >>>rails doesn''t do... >>> >>> >>exactly !!!! :) >> >> > >I don''t want to be too much of a curmudgeon. But Customer is a person >is, *literally*, a textbook case of abusing inheritance. Continuing >this approach > >What about staff members? They''re Persons too? Staff is a Person? > >Then what about Staff members who are Customers? StaffCustomer < >Staff, Customer? > >Then what about Customers who used to be Staff members? You have to >take a StaffCustomer (which isn''t possible in ruby) and transmogrify >it into a Customer. Also not possible in ruby. > >What you''re after is: > >Customer belongs to Person >Staff belongs to Person > >And yes, that means you can''t go user.name, > >Yes that is a horrible use of it. There are situations where I would want to be able to do class to table type of inheritance... does it kill me to do it another way? no... does it bother me that my models really reflect to much of the database? yes would i like another option for select situations? yes would i use it often? no am i going to ask anyone else to implement it? no, i dont think its that important. when i really need it, i''ll do it myself but back to your example... how would you do a staff member who is also a customer? seems to me you would have a staff member instance and a different customer instance both of which have a person_id so in that case you dont really have a StaffCustomer either so why go dragging that in with the Class table relationship when I could do... Customer is a person StaffMember is a person at which point either way is at the same point and neither is really ugly... i would be really interested in seeing how a belongs_to would deal with a StaffCustomer... because I can''t see it... other than perhaps finding any staff and customers who shared the same person_id But lets go a bit further... Lets say we are dealing with people and companies and each has many addresses further just to be simplistic lets say a person is an address, first name and last name whereas a company is just a name and an address how am i going to do that has it stands now... with STI i could have name first name last name type and have address point over to that STI... personally i dont like that... i can use postgresql table inheritance and have base like address_entity that has many addresses then inherit people and companies from that each with its own additional fields... or back to mysql i could do person like people: person_id entity_id first_name last_name entities: entity_id addresses: address_id entity_id etc etc but then in my views i have to do... person.entity.addresses that is more exposure then i want... personally i''ve come around to like something like a belongs_to but more magical... call it is_a for the sake of this... in the mysql example above... i still have the same database layout but is_a does delegation of anything that would be person.entity directly so i can just do person.address and hide that implementation detail... i havent fully worked through this because i just switched to pgsql and its table inheritance and the issues that will bring but having the above as an option is something that i would like and at somepoint, i''ll implement it... actually using Person < Entity i havent looked at that a whole lot put it really seems from a quick perusal that i can get the same functionality with less pain using is_a instead of actually ruby inheritance... and yes, it could be abused but it could also be useful in certain situations... _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On 6/17/05, Sean T Allen <sean-5W9FBhQXBOtBDgjK7y7TUQ@public.gmane.org> wrote:> am i going to ask anyone else to implement it? > > no, i dont think its that important. when i really need it, i''ll do it > myselfExcellent ! ;) The more the merrier.> but back to your example... > > how would you do a staff member who is also a customer? > > seems to me you would have a staff member instance and a different > customer instance > both of which have a person_idI can see where you''re coming from, but what you''re really describing is some kind of setter magic rather than inheritance. Your object model is still Customer has a Person, StaffMember has a Person. c = Customer.find(1) s = StaffMember.find(2) # c and s both share the same ''row'' in people or instance of Person if you''re an OO # head like me c.name="steve" s.name="bob" What are we meant to do here?> Lets say we are dealing with people and companies and each has many > addresses > > further just to be simplistic lets say a person is an address, first > name and last name whereas a company is just a name and an address> personally i''ve come around to like something like a belongs_to but more > magical... call it is_a for the sake of this... > > in the mysql example above... i still have the same database layout > but is_a does delegation of anything that would be person.entity > directly so i can just do person.address and hide that implementation > detail...Sounds like some kind of clever delegate, not an IS-A at all. There was talk of something like that in Java a while back. It looked like this: public class Something implements ISomeOtherThing { private ISomeOtherThing sot; delegates ISomeOtherThing to sot; } You could do that with a method in Rails like class Something < ActiveRecord::Base belongs_to :some_other_thing, :class_name=>"SomeOtherThing" delegates SomeOtherThing, :to=>:some_other_thing end Sounds like a useful enhancement for rails 2.0, or a gem people could require? I''ve no problem with that kind of thing, in fact it looks quite useful. However it''s most certainly *not* inheritance.> i havent fully worked through this because i just switched to pgsql and > its table inheritance and the issues that will bring but having the > above as an option is something that i would like and at somepoint, i''ll > implement it... > > actually using Person < EntityNow we disagree ;) as that''s not your domain model at all. But whatever floats your boat, you''re implementing it after all.> i havent looked at that a whole lot put it really seems from a quick > perusal that i can get the same functionality with less pain using is_a > instead of actually ruby inheritance... > > and yes, it could be abused but it could also be useful in certain > situations...Sure, but the original poster said: "i find this AN ENORMOUS limitation of active record and i want to know if it''s planned to make this aspect of AR change..." Which is the polar opposite of what your position is ;)> > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > > >-- Cheers Koz
>>but back to your example... >> >>how would you do a staff member who is also a customer? >> >>seems to me you would have a staff member instance and a different >>customer instance >>both of which have a person_id >> >> > >I can see where you''re coming from, but what you''re really describing >is some kind of setter magic rather than inheritance. Your object >model is still Customer has a Person, StaffMember has a Person. > >c = Customer.find(1) >s = StaffMember.find(2) > ># c and s both share the same ''row'' in people or instance of Person if >you''re an OO ># head like me > >c.name="steve" >s.name="bob" > >What are we meant to do here? > > >i think in that case it is ''bob'' but how else would you deal with this were someone can be a staff member and a customer? i''d be interested for your idea on it... really i dont have a problem free solution to that issue... and any thoughts are more than welcome because i''m sure this will come up in my life eventually... why it hasnt up to now is actually a little beyond me...>>Lets say we are dealing with people and companies and each has many >>addresses >> >>further just to be simplistic lets say a person is an address, first >>name and last name whereas a company is just a name and an address >> >> > > > > >>personally i''ve come around to like something like a belongs_to but more >>magical... call it is_a for the sake of this... >> >>in the mysql example above... i still have the same database layout >>but is_a does delegation of anything that would be person.entity >>directly so i can just do person.address and hide that implementation >>detail... >> >> > >Sounds like some kind of clever delegate, not an IS-A at all. There >was talk of something like that in Java a while back. It looked like >this: > >public class Something implements ISomeOtherThing >{ > private ISomeOtherThing sot; > delegates ISomeOtherThing to sot; >} > >You could do that with a method in Rails like > >class Something < ActiveRecord::Base > belongs_to :some_other_thing, :class_name=>"SomeOtherThing" > > delegates SomeOtherThing, :to=>:some_other_thing >end > >Sounds like a useful enhancement for rails 2.0, or a gem people could >require? I''ve no problem with that kind of thing, in fact it looks >quite useful. However it''s most certainly *not* inheritance. > > >True its not. Basically my response was a couple things... 1. I dont see how the staff member who is also a customer is adequately dealt with by either situation... 2. proposing a basic idea which gets you benefits of inheritance without actually doing inheritance ( and hopefully avoiding problems. ).>>i havent fully worked through this because i just switched to pgsql and >>its table inheritance and the issues that will bring but having the >>above as an option is something that i would like and at somepoint, i''ll >>implement it... >> >>actually using Person < Entity >> >> > >Now we disagree ;) as that''s not your domain model at all. But >whatever floats your boat, you''re implementing it after all. > > >Actually i dont think we have a disagreement, my spacing and grammar just sucked... let me try that again... take 2: i havent fully worked through this because i just switched to pgsql and its table inheritance and the issues that will bring but having the above as an option is something that i would like and at somepoint, i''ll implement it. actually using Person < Entity, i havent looked at that a whole lot put it really seems from a quick perusal that i can get the same functionality with less pain using ''is_a'' instead of actually ruby inheritance... end take 2 where of course ''is_a'' mean some form of delegation... because well i was playing fast and loose with terminology to try to convey the end goal rather than an actual implementation...>>i havent looked at that a whole lot put it really seems from a quick >>perusal that i can get the same functionality with less pain using is_a >>instead of actually ruby inheritance... >> >>and yes, it could be abused but it could also be useful in certain >>situations... >> >> > >Sure, but the original poster said: > >"i find this AN ENORMOUS limitation of active record and i want to >know if it''s planned to make this aspect of AR change..." > >Which is the polar opposite of what your position is ;) > >true enough... i dont see it as an enormous limitation... when i first came over to rails a couple monthes ago that was my initial reaction tho because i''d been using perl classes that did do inheritance but behind the scenes actually did delegation... it was kind of a mess inside but from the outside it sure looked pretty... after playing around a bit more i realized it wasnt an enormous limitation... there are perfectly workable ways around it... _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Sean T Allen wrote:> >>> but back to your example... >>> >>> how would you do a staff member who is also a customer? >>> >>> seems to me you would have a staff member instance and a different >>> customer instance >>> both of which have a person_id >>> >> >> >> I can see where you''re coming from, but what you''re really describing >> is some kind of setter magic rather than inheritance. Your object >> model is still Customer has a Person, StaffMember has a Person. >> >> c = Customer.find(1) s = StaffMember.find(2) >> # c and s both share the same ''row'' in people or instance of Person if >> you''re an OO >> # head like me >> >> c.name="steve" >> s.name="bob" >> >> What are we meant to do here? >> >> >> > > i think in that case it is ''bob'' >i think i should have been more clear here... if you have c = Customer.find(1) s = StaffMember.find(2) c.name = "steve" s.name = "bob" then the name ends up as whichever is saved last... c.save s.save would result in the name being ''bob'' which i would call correct if the customer and the staff member are the same person. _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Lets try that again... I''m going to [snip] vigourously here for everyone else''s sake On 6/17/05, Sean T Allen <sean-5W9FBhQXBOtBDgjK7y7TUQ@public.gmane.org> wrote:> >c.name="steve" > >s.name="bob" > > > >What are we meant to do here? > i think in that case it is ''bob'' (assuming s is saved last)That''s how we view it as programmers, but setting some customer''s name and having a staff member get changed is almost certainly not what a user would expect.> but how else would you deal with this were someone can be a staff member > and a customer?Depends on the requirements. Unfortunately I can''t post my employers code, (jail time isn''t cool). But here''s a really simple version. Customer belongs_to :person StaffMember belongs_to :person Person has_one :customer Person has_one :staff_member That''s it. If you want to get a Customer''s name, use @customer.person.name. No magic, no delegates, nothing. Sure it''s 8 more chars to type, no worries.> i''d be interested for your idea on it... > > really i dont have a problem free solution to that issue...Mine is just to ignore it entirely, the business differentiates between them, you''re splitting the data up for a reason, those reasons almost certainly apply to the code. And to anyone who says ''performance'', we do more load than you do and it works fine. :) -- Cheers Koz -- Cheers Koz
Michael Koziarski wrote:>Lets try that again... > >I''m going to [snip] vigourously here for everyone else''s sake > >On 6/17/05, Sean T Allen <sean-5W9FBhQXBOtBDgjK7y7TUQ@public.gmane.org> wrote: > > >>>c.name="steve" >>>s.name="bob" >>> >>>What are we meant to do here? >>> >>> >>i think in that case it is ''bob'' (assuming s is saved last) >> >> > >That''s how we view it as programmers, but setting some customer''s >name and having a staff member get changed is almost certainly not >what a user would expect. > > >well i think that depends on whether the user considers them the same person or not. if they are the same person then i one the user end would expect changing one to change the other...>>but how else would you deal with this were someone can be a staff member >>and a customer? >> >> > >Depends on the requirements. Unfortunately I can''t post my employers >code, (jail time isn''t cool). But here''s a really simple version. > >Customer belongs_to :person >StaffMember belongs_to :person > >Person has_one :customer >Person has_one :staff_member > >That''s it. If you want to get a Customer''s name, use >@customer.person.name. No magic, no delegates, nothing. Sure it''s >8 more chars to type, no worries. > > >Wouldnt that if you lead to exactly the issue above... since Customer and StaffMember share the same person instance... changing one changes the other... with has_one relationship i like the way you have it as well... i only dont like it in the has_many type scenario i described where you are exposing what is completely an implementation detail. _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
> well i think that depends on whether the user considers them the same > person or not. > > if they are the same person then i one the user end would expect > changing one to change > the other...Yeah, but in the code above, developers may not fully grasp the situation. Afterall, you''re just setting that thing''s name right?> Wouldnt that if you lead to exactly the issue above... > > since Customer and StaffMember share the same person instance... > changing one changes the other...Yes, but it''s explicit, you''re change the Person instance, not calling some method on the StaffMember or Customer which magically changes things. That''s really the only difference.> with has_one relationship i like the way you have it as well... > > i only dont like it in the has_many type scenario i described where you > are exposing what is completely an implementation detail.In the person, customer case It''s not an implementation detail, it''s part of the domain. In the other case, it''s not part of the domain, so I''d just duplicate the data and be done with it. KISS and all that ;)> > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > > >-- Cheers Koz