[deleted original post by accident] http://dev.catalyst.perl.org/wiki/VersusRails Hmm, I don''t know, I think it''s pretty fair and accurate. I can imagine some people getting all uppity in their seats though when they hit the last row, the "best suited for" line on Rails: """ Web-focused fresh (non-legacy) projects with simple-to-moderate data model requirements. Due to the simplistic nature of Rails, the framework has certain limitations that can cause headaches later for more complex projects. Rails is criticized as being overhyped and branding/marketing mostly old ideas as new. """ -- ________________________________ toddgrimason*todd[ at ]slack.net
Todd Grimason wrote:> [deleted original post by accident] > > http://dev.catalyst.perl.org/wiki/VersusRails > > Hmm, I don''t know, I think it''s pretty fair and accurate. > > I can imagine some people getting all uppity in their seats though when > they hit the last row, the "best suited for" line on Rails: > > > """ > Web-focused fresh (non-legacy) projects with simple-to-moderate data > model requirements. Due to the simplistic nature of Rails, the framework > has certain limitations that can cause headaches later for more complex > projects. Rails is criticized as being overhyped and branding/marketing > mostly old ideas as new. > """ >Humm, I agree. How would you put it? For context, the Catalyst side is: "More complex projects that need to draw from a larger library and developer base. Due to the nature of more control and flexibility, project code can be more complex. Catalyst is criticized as playing catch-up to Rails, and for not having as complete documentation or presence. Catalyst has a steeper learning curve than Rails." Phil
* Philip Edelbrock [2005-08-17 18:31]:> Humm, I agree. How would you put it?Oh I totally agree as well. Just trying to start trouble :-) -- ________________________________ toddgrimason*todd[ at ]slack.net
Todd Grimason wrote:> * Philip Edelbrock [2005-08-17 18:31]: > > >>Humm, I agree. How would you put it? > > > Oh I totally agree as well. Just trying to start trouble :-) >Well, I''m not looking for trouble! :'') I toned down that last row a bit. Best Suited Application- Catalyst: More complex projects that need to draw from a larger library and developer base. Due to the nature of more control and flexibility, project code can be more complex. Rails: Web-focused fresh (non-legacy) projects with simple-to-moderate data model requirements. With intended simplicity, there is some loss of flexibility. Phil
On Aug 17, 2005, at 4:39 PM, Philip Edelbrock wrote:> I toned down that last row a bit. > > Best Suited Application- > > Catalyst: > More complex projects that need to draw from a larger library and > developer base. Due to the nature of more control and flexibility, > project code can be more complex. > > Rails: > Web-focused fresh (non-legacy) projects with simple-to-moderate > data model requirements. With intended simplicity, there is some > loss of flexibility.I completely agree with the "non-legacy" aspect of your statement, as well as the "some loss of flexibility" statement. However, there seems to be a perception among techie types that a set of sensible defaults and assumptions somehow equates to "less powerful". It is certainly less configurable than some other tools, but does that really make it less powerful? If you can still do all the things "the other guys" can do, is it any less capable? I suppose you can always find some definition of "powerful" for which your entire statement holds. Also, people tend to think that Rails isn''t Rails if you aren''t using ActiveRecord. This isn''t true. You can use 2/3 (or more) of the standard Rails bundle and simply plug in your ORM of choice. You can still use ActionController, ActionView, ActiveSupport, ActionMailer, and SwitchTower, even if you don''t use AR. - Jamis
> I completely agree with the "non-legacy" aspect of your > statement, as well as the "some loss of flexibility" > statement. However, there seems to be a perception among > techie types that a set of sensible defaults and assumptions > somehow equates to "less powerful". It is certainly less > configurable than some other tools, but does that really make > it less powerful? If you can still do all the things "the > other guys" can do, is it any less capable? I suppose you can > always find some definition of "powerful" for which your > entire statement holds.Yes, no argument on the technical aspects of the comparisons but to kind of add to what Jamis says above, what I don''t think I''m seeing/reading in these reviews and comparisons are the *philosophical* differences between Language+WebAppFramework Brand A vs. Language+WebAppFramework Brand B. In many ways, that is the __key__ to these differences. For example, there''s a philosophical difference between seeing something that''s "more flexible" and seeing the same thing as, "make everything equally difficult" and I don''t know if either is "right" or "wrong". It''s just a different way of seeing things. I''m sure Larry Wall (is that creator of Perl''s name?) and Kaz have very different philosophies with designing programming languages; DHH has some pretty strong opinions and it''s all reflected in their work. So, not trying to make trouble and hoping this take is somewhat helpful.
Todd Grimason wrote:> I can imagine some people getting all uppity in their seats though when > they hit the last row, the "best suited for" line on Rails:Yea. People tend to get uppity when you feed them bs. No but really, I''m dying to see one of these complex model setups that impossible in Rails. I''m serious. Let''s hear them.
* Nicholas Seckar [2005-08-17 20:05]:> Todd Grimason wrote: > >I can imagine some people getting all uppity in their seats though when > >they hit the last row, the "best suited for" line on Rails: > > Yea. People tend to get uppity when you feed them bs. > > No but really, I''m dying to see one of these complex model setups that > impossible in Rails. > > I''m serious. Let''s hear them.Impossible? I don''t think it said that, I don''t think I said it... the wiki originally said "Due to the simplistic nature of Rails, the framework has certain limitations that can cause headaches later for more complex projects" Which doesn''t sound like ''impossible'' to me. Sounded more like a reflection of Catalyst''s decision to use more of a "very flexible/all equally hard" approach rather than the comfy fit of AR in Rails. As someone else said, diff philosophies. You''d have to ask someone who makes the "impossible" claim to give an example. I just find it surprising when people get uppity over such issues... -- ________________________________ toddgrimason*todd[ at ]slack.net
On Aug 17, 2005, at 8:02 PM, Nicholas Seckar wrote:> Todd Grimason wrote: > >> I can imagine some people getting all uppity in their seats though >> when >> they hit the last row, the "best suited for" line on Rails: >> > > Yea. People tend to get uppity when you feed them bs. > > No but really, I''m dying to see one of these complex model setups > that impossible in Rails. > > I''m serious. Let''s hear them.Someone else dealt with your straw-man argument, but I''m curious: What do you think are Rail''s deficiencies? If you could get us fifth columnists to shut up and contribute code, what would you have us work on? Regards, Ed -- Transmogrify, LLC * <http://xmog.com/>
* Ed Watkeys [2005-08-17 21:18]:> > On Aug 17, 2005, at 8:02 PM, Nicholas Seckar wrote: > > >Todd Grimason wrote: > > > >>I can imagine some people getting all uppity in their seats though > >>when > >>they hit the last row, the "best suited for" line on Rails: > >> > > > >Yea. People tend to get uppity when you feed them bs. > > > >No but really, I''m dying to see one of these complex model setups > >that impossible in Rails. > > > >I''m serious. Let''s hear them. > > Someone else dealt with your straw-man argument, but I''m curious: > What do you think are Rail''s deficiencies? If you could get us fifth > columnists to shut up and contribute code, what would you have us > work on? >Straw man arguments? Fifth columnists? What is going on? Are we discussing the war or politics all of a sudden? I said I agreed overall with the original wiki info, but that Rails folk would probably take exception to the tone of the last entry. I didn''t write the wiki. I have no problems with Rails, and even if I hated it would happily use it rather than go back to perl. I don''t quite understand the freakout here I guess, there seems to have been some sort of mixup... -- ________________________________ toddgrimason*todd[ at ]slack.net
Todd Grimason wrote:>>Someone else dealt with your straw-man argument,For the record, my straw man is still waiting for an complex model situtation that spawns headaches when attempted using AR. Complaining over the exact use of words doesn''t constitute a refution to me. Anyhow, he''s still waiting. Please don''t leave him too long without an answer or I''ll have to feed him to the horse.>> but I''m curious: >>What do you think are Rail''s deficiencies? If you could get us fifth >>columnists to shut up and contribute code, what would you have us >>work on?At the moment error messages could use some love. This is partially due to developments that have happened since 0.13.1 was released. A lot of people play down the importance of error messages, but they really belong fairly high on the priority list, as attempting to debug code without good error messages is an exercise in frustration. If you want to start contributing to Rails, the best thing I suggest is to read Rails'' source and add test cases where you feel they are lacking. Patches containing test cases are always welcome. Additions of new features are met with more skeptism and must face "Does this need to be part of rails, or can it function as an external library or extension?"
On Aug 17, 2005, at 9:24 PM, Todd Grimason wrote:> * Ed Watkeys [2005-08-17 21:18]: > >> Someone else dealt with your straw-man argument, but I''m curious: >> What do you think are Rail''s deficiencies? If you could get us fifth >> columnists to shut up and contribute code, what would you have us >> work on? >> >> > > Straw man arguments? Fifth columnists? What is going on? Are we > discussing the war or politics all of a sudden? > > I said I agreed overall with the original wiki info, but that Rails > folk > would probably take exception to the tone of the last entry. I didn''t > write the wiki. I have no problems with Rails, and even if I hated it > would happily use it rather than go back to perl. > > I don''t quite understand the freakout here I guess, there seems to > have > been some sort of mixup...Some people A think that some other people B won''t shut up about certain issues that they think are futile, when what''s really going on is that people B are mostly reacting to the seething hostility dripping from the comments of people A. If I had to guess, people A see a slow but steady trickle of people asking the same questions -- e.g. what''s the deal with this pluralization crap? -- and it gets old really fast. People B hear people A saying that: * You don''t get the (Rails|Ruby) philosophy. * Go back to Struts programming! * Why don''t you just fork Rails and STFU? * DHH designed it: Respect! * -20 * Why do all these people complain? Everyone likes it the way it is. I''m not claiming the high road here: I pretty much came out and called people who like to pluralize table names morons. I''m sorry about that. But there are solutions to these issues that don''t entail showing the door to people who hold contrary opinions. For example, someone suggested putting a bunch of common configuration options in the environment.rb file. That addresses my concern, namely that people shouldn''t have to hop on #rubyonrails or join this mailing list to figure out how to set up Rails to work the way they want it to. Regards, Ed -- Transmogrify, LLC * <http://xmog.com/>
Zed A. Shaw
2005-Aug-18 03:28 UTC
Ternary and attributed relationships in AR (Was: Catalyst/Rails)
Hi, This isn''t a confrontational argument, but more of a demonstration of two things that I''ve found difficult in AR. I actually asked this on IRC before reading this thread and didn''t get a response there. I''m interested in how this would be solved in AR and not in how AR sucks (take that to a Java list or something). TERNARY RELATIONSHIPS The application I''m working on is a prison Incident Reporting System. Yes, it''s a real system, and yes we''re using Rails for it. In our first cut of the system we had three objects: Staff, Inmate, and Incident. I abandonded this model though because, in order to model the "involved in" it would require a ternary relationship that connected Staff, Inmate, and Incident together and I couldn''t get it to work. For example: I have the tables staff, inmates, incidents. I need a single incidents_staff_inmates table (which we originally called "involvement" but still didn''t help). In addition this relation needs to be M:M:M (an involvement has many staff, inmates, and incidents potentially), but the incident could be relaxed to a single one. While the standard response to this is "don''t do that, what you should do is..." it doesn''t respond to the problem that there''s no clear way to model this kind of ternary relationship in AR (that I know of). Also, this shows up quite frequently in practice and is something that many frameworks just don''t model well, so not only AR would be lacking. ATTRIBUTED RELATIONS We dropped the idea of the ternary relationship and instead generalized Inmate and Staff to Person. This got rid of the ternary relationship (and is about the only nice way to do this) and we just use a flag to determine if a person is an Inmate or Staff. But, then the "attributed relation" problem popped up. As before, I have an Incident, it has many People invovled, and that''s done with a HABTM of incidents_people. Pretty simple so far, nothing too bad. Person.incidents and Incident.people all there. Now, each person''s involvement has a set of attributes for the type of injury they sustained, and how they sustained it. Thus, the best place to attach this injury_type and injury_cause is on the incidents_people relationship, since it is basically an attribute of this relationship between each person and their incident. Normally, I would just add two extra columns to this relation table. Before you think I can put this on Incident, remember this is each Person''s involvement, so there''s one set of extra attributes for each Person:Incident connection. Any ideas? Hopefully throwing rocks at the straw man will get other people to do my dirty work. Dance monkeys! And, I appreciate the help too. Zed A. Shaw http://www.zedshaw.com/ On Wed, 17 Aug 2005 21:47:56 -0400 Nicholas Seckar <nseckar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> For the record, my straw man is still waiting for an complex model > situtation that spawns headaches when attempted using AR. Complaining > over the exact use of words doesn''t constitute a refution to me.
Jeff Moss
2005-Aug-18 03:37 UTC
Re: Ternary and attributed relationships in AR (Was: Catalyst/Rails)
Your ternary relationship should work fine, just use the table with the three columns, one for incident, one for staff and one for inmate, and use has_and_belongs_to_many :incidents in both staff and inmates. You will never have both staff and inmate columns populated in the same row. The attributed relationship should work fine also, just put the extra data in the incidents_people table, has_and_belongs_to_many documentation describes this: "Any additional fields added to the join table will be placed as attributes when pulling records out through has_and_belongs_to_many <http://api.rubyonrails.com/classes/ActiveRecord/Associations/ClassMethods.html#M000430> associations. This is helpful when have information about the association itself that you want available on retrieval. Note that any fields in the join table will override matching field names in the two joined tables. As a consequence, having an "id" field in the join table usually has the undesirable result of clobbering the "id" fields in either of the other two tables." -Jeff Zed A. Shaw wrote:>Hi, > >This isn''t a confrontational argument, but more of a demonstration of two things that I''ve found difficult in AR. I actually asked this on IRC before reading this thread and didn''t get a response there. I''m interested in how this would be solved in AR and not in how AR sucks (take that to a Java list or something). > >TERNARY RELATIONSHIPS > >The application I''m working on is a prison Incident Reporting System. Yes, it''s a real system, and yes we''re using Rails for it. > >In our first cut of the system we had three objects: Staff, Inmate, and Incident. I abandonded this model though because, in order to model the "involved in" it would require a ternary relationship that connected Staff, Inmate, and Incident together and I couldn''t get it to work. > >For example: I have the tables staff, inmates, incidents. I need a single incidents_staff_inmates table (which we originally called "involvement" but still didn''t help). In addition this relation needs to be M:M:M (an involvement has many staff, inmates, and incidents potentially), but the incident could be relaxed to a single one. > >While the standard response to this is "don''t do that, what you should do is..." it doesn''t respond to the problem that there''s no clear way to model this kind of ternary relationship in AR (that I know of). Also, this shows up quite frequently in practice and is something that many frameworks just don''t model well, so not only AR would be lacking. > >ATTRIBUTED RELATIONS > >We dropped the idea of the ternary relationship and instead generalized Inmate and Staff to Person. This got rid of the ternary relationship (and is about the only nice way to do this) and we just use a flag to determine if a person is an Inmate or Staff. But, then the "attributed relation" problem popped up. As before, I have an Incident, it has many People invovled, and that''s done with a HABTM of incidents_people. Pretty simple so far, nothing too bad. Person.incidents and Incident.people all there. > >Now, each person''s involvement has a set of attributes for the type of injury they sustained, and how they sustained it. Thus, the best place to attach this injury_type and injury_cause is on the incidents_people relationship, since it is basically an attribute of this relationship between each person and their incident. Normally, I would just add two extra columns to this relation table. > >Before you think I can put this on Incident, remember this is each Person''s involvement, so there''s one set of extra attributes for each Person:Incident connection. > >Any ideas? Hopefully throwing rocks at the straw man will get other people to do my dirty work. Dance monkeys! > >And, I appreciate the help too. > >Zed A. Shaw >http://www.zedshaw.com/ > >On Wed, 17 Aug 2005 21:47:56 -0400 >Nicholas Seckar <nseckar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > >>For the record, my straw man is still waiting for an complex model >>situtation that spawns headaches when attempted using AR. Complaining >>over the exact use of words doesn''t constitute a refution to me. >> >> >_______________________________________________ >Rails mailing list >Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >http://lists.rubyonrails.org/mailman/listinfo/rails > >
Steven
2005-Aug-18 03:57 UTC
Re: Ternary and attributed relationships in AR (Was: Catalyst/Rails)
On Wed, 2005-08-17 at 23:28 -0400, Zed A. Shaw wrote:> We dropped the idea of the ternary relationship and instead > generalized Inmate and Staff to Person. This got rid of the ternary > relationship (and is about the only nice way to do this) and we just > use a flag to determine if a person is an Inmate or Staff. But, then > the "attributed relation" problem popped up. As before, I have an > Incident, it has many People invovled, and that''s done with a HABTM of > incidents_people. Pretty simple so far, nothing too bad. > Person.incidents and Incident.people all there. > > Now, each person''s involvement has a set of attributes for the type of > injury they sustained, and how they sustained it. Thus, the best > place to attach this injury_type and injury_cause is on the > incidents_people relationship, since it is basically an attribute of > this relationship between each person and their incident. Normally, I > would just add two extra columns to this relation table. > > Before you think I can put this on Incident, remember this is each > Person''s involvement, so there''s one set of extra attributes for each > Person:Incident connection. > > Any ideas? Hopefully throwing rocks at the straw man will get other > people to do my dirty work. Dance monkeys!So you have incidents and people, but an incident has participants. So an incident has many participants and a participant has one person and one incident. With the link being a first class object, you can get to any of the information you want. At least this is one option. -- Steven Critchfield critch-wQLwMjUOumVBDgjK7y7TUQ@public.gmane.org KI4KTY
Zach Dennis
2005-Aug-18 04:23 UTC
Re: Ternary and attributed relationships in AR (Was: Catalyst/Rails)
Zed A. Shaw wrote:> Hi, > > This isn''t a confrontational argument, but more of a demonstration of two things that I''ve found difficult in AR. I actually asked this on IRC before reading this thread and didn''t get a response there. I''m interested in how this would be solved in AR and not in how AR sucks (take that to a Java list or something). > > TERNARY RELATIONSHIPS > > The application I''m working on is a prison Incident Reporting System. Yes, it''s a real system, and yes we''re using Rails for it. > > In our first cut of the system we had three objects: Staff, Inmate, and Incident. I abandonded this model though because, in order to model the "involved in" it would require a ternary relationship that connected Staff, Inmate, and Incident together and I couldn''t get it to work. > > For example: I have the tables staff, inmates, incidents. I need a single incidents_staff_inmates table (which we originally called "involvement" but still didn''t help). In addition this relation needs to be M:M:M (an involvement has many staff, inmates, and incidents potentially), but the incident could be relaxed to a single one. > > While the standard response to this is "don''t do that, what you should do is..." it doesn''t respond to the problem that there''s no clear way to model this kind of ternary relationship in AR (that I know of). Also, this shows up quite frequently in practice and is something that many frameworks just don''t model well, so not only AR would be lacking. >Using the three table structure you have set up you would probably break it down into: inmate -> inmate_incident -> incident staff -> staff_incident -> incident so you''d end up with the tables; inmate, staff, inmate_incident, staff_incident and incident> ATTRIBUTED RELATIONS > > We dropped the idea of the ternary relationship and instead generalized Inmate and Staff to Person. This got rid of the ternary relationship (and is about the only nice way to do this) and we just use a flag to determine if a person is an Inmate or Staff. But, then the "attributed relation" problem popped up. As before, I have an Incident, it has many People invovled, and that''s done with a HABTM of incidents_people. Pretty simple so far, nothing too bad. Person.incidents and Incident.people all there. > > Now, each person''s involvement has a set of attributes for the type of injury they sustained, and how they sustained it. Thus, the best place to attach this injury_type and injury_cause is on the incidents_people relationship, since it is basically an attribute of this relationship between each person and their incident. Normally, I would just add two extra columns to this relation table. > > Before you think I can put this on Incident, remember this is each Person''s involvement, so there''s one set of extra attributes for each Person:Incident connection. > > Any ideas? Hopefully throwing rocks at the straw man will get other people to do my dirty work. Dance monkeys!If you don''t want to have 2 extra attributes floating around for Person:Incidents when someone didn''t get injured or harmed just split it off. person -> person_incident -> incident injury -> person_incident so you''d end up with tables; person, person_incident, incident and injury this forces there to be a person_incident record for any injury reported, and it allows you to save some space because now you won''t have the extra injury-related attributes for each person_incident record created. And since person_incident will probably have a field person_id you can rest assure that you can find the person a given injury occured on through the link with person_incident. Just my first impression... Zach
Tyler Kiley
2005-Aug-18 06:04 UTC
Re: Ternary and attributed relationships in AR (Was: Catalyst/Rails)
> For example: I have the tables staff, inmates, incidents. I need a single incidents_staff_inmates table (which we originally called "involvement" but still didn''t help). In addition this relation needs to be M:M:M (an involvement has many staff, inmates, and incidents potentially), but the incident could be relaxed to a single one.Color me a heretic, but I''ve fudged over a few of these sorts of problems by turning complex relationships into real tables, and creating a few accessor methods to hide the added complexity from the rest of the app. (You can easily do three-way relationships that way, and other nifty things like acts_as_sort on a habtm association) Tyler
Zed A. Shaw
2005-Aug-18 06:38 UTC
Re: Ternary and attributed relationships in AR (Was: Catalyst/Rails)
On Thu, 18 Aug 2005 00:23:35 -0400 Zach Dennis <zdennis-aRAREQmnvsAAvxtiuMwx3w@public.gmane.org> wrote:> Zed A. Shaw wrote: > > Using the three table structure you have set up you would probably break > it down into: > > inmate -> inmate_incident -> incident > staff -> staff_incident -> incident > > so you''d end up with the tables; inmate, staff, inmate_incident, > staff_incident and incidentYes, but that''s not a Ternary relationship now is it? :-) It also doesn''t really answer how AR handles this. The additional problem we found was that your above model, while it might work, misses the staff <--> inmate connection, which is part of a ternary relationship.> > If you don''t want to have 2 extra attributes floating around for > Person:Incidents when someone didn''t get injured or harmed just split it > off. > > person -> person_incident -> incident > > injury -> person_incident > > so you''d end up with tables; person, person_incident, incident and injury > > this forces there to be a person_incident record for any injury > reported, and it allows you to save some space because now you won''t > have the extra injury-related attributes for each person_incident record > created. And since person_incident will probably have a field person_id > you can rest assure that you can find the person a given injury occured > on through the link with person_incident.Yes, you''ve attached the injury attribute to the person_incident, but the problem is more how AR deals with this, not how you''d structure the database. Also, you''re missing *how* injury is related to person_incident. A column in person_incident? A column in injury? What''s the ID? If I read above correctly, you would make a new record in injury for every person that had an injury and then attach injury_type and injury_cause to that. Still doesn''t answer the additional problem of how you go from Incident in AR to injury_type. It get messy and you''re basically on the same track I''m at right now. Thanks for the thoughts though. Think it over more and let me know if you come up with something. This is really the one I need to figure out since I have to do it soonish. Zed A. Shaw http://www.zedshaw.com/
Zed A. Shaw
2005-Aug-18 06:44 UTC
Re: Ternary and attributed relationships in AR (Was: Catalyst/Rails)
On Wed, 17 Aug 2005 22:57:49 -0500 Steven <critch-wQLwMjUOumVBDgjK7y7TUQ@public.gmane.org> wrote:> On Wed, 2005-08-17 at 23:28 -0400, Zed A. Shaw wrote: > > > Now, each person''s involvement has a set of attributes for the type of > > injury they sustained, and how they sustained it. Thus, the best> So you have incidents and people, but an incident has participants. So > an incident has many participants and a participant has one person and > one incident. > > With the link being a first class object, you can get to any of the > information you want.If you re-read your idea, you''ll notice you don''t mention involvement, or injury type, or injury causes. Another way to explain the problem in AR terms is, imagine if when I do Incident.people, I can also get additional "meta" information about each connected person that says what injury type and cause they have. Also, the inverse Person.incidents would give the same. The injury type and cause is attached to the person and incidents fields, not to Person or Incident, but the connection. This is basically adding attributes to the Incidents.people and Person.incidents connections. So, the question is how would AR handle this? Zed A. Shaw http://www.zedshaw.com/
Zed A. Shaw
2005-Aug-18 06:49 UTC
Re: Ternary and attributed relationships in AR (Was: Catalyst/Rails)
On Wed, 17 Aug 2005 21:37:48 -0600 Jeff Moss <jeff-61uStg5MtoFWk0Htik3J/w@public.gmane.org> wrote:> Your ternary relationship should work fine, just use the table with the > three columns, one for incident, one for staff and one for inmate, and > use has_and_belongs_to_many :incidents in both staff and inmates. You > will never have both staff and inmate columns populated in the same row. >Well, last I tried it, AR did not like that at all, and really didn''t like the extra fields, but I''ll give this a try again and see how it works. First problem is the "convention" didn''t like a strange name and pretty much insisted on incidents_staff or incidents_inmate. Second thing I ran into was the ids got all screwy. I''ll play with it using the new AR though, and report back how it works though.> The attributed relationship should work fine also, just put the extra > data in the incidents_people table, has_and_belongs_to_many > documentation describes this: > > "Any additional fields added to the join table will be placed as > attributes when pulling records out through has_and_belongs_to_many > <http://api.rubyonrails.com/classes/ActiveRecord/Associations/ClassMethods.html#M000430> > associations. This is helpful when have information about the > association itself that you want available on retrieval. Note that any > fields in the join table will override matching field names in the two > joined tables. As a consequence, having an "id" field in the join table > usually has the undesirable result of clobbering the "id" fields in > either of the other two tables." >Now this should work perfectly. Not really clear how you actually know that the attributes aren''t part of the objects retrieved this way, but I''ll try that out and see how it works. Thanks Jeff!
"Zed A. Shaw" <zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org> writes:>> Using the three table structure you have set up you would probably break >> it down into: >> >> inmate -> inmate_incident -> incident >> staff -> staff_incident -> incident >> >> so you''d end up with the tables; inmate, staff, inmate_incident, >> staff_incident and incident > > Yes, but that''s not a Ternary relationship now is it? :-) It also > doesn''t really answer how AR handles this. The additional problem > we found was that your above model, while it might work, misses the > staff <--> inmate connection, which is part of a ternary > relationship.No, it''s not a ternary relationship; but doesn''t it model your problem? The idea of having inmates and staff both as people though has some merit. The classic problem when one type of person becomes another type of person. Anyway, you can manually tie inmates to staff with the above by writing a shortcut method. Maybe something like this: class Staff has_and_belongs_to_many :incidents def inmates @incidents ||= incidents.collect { |i| i.inmates }.flatten end end That would return all the inmates that have been in incident with that staff person. I''ve said this before, but when you start having attributes on your join tables, it''s probably best to make a separate class for the join. You''d have the tables staff, incidents, incidents_staff, inmates, incidents_inmates and then these models: class Staff has_many :incidents_staff end class Inmates has_many :incidents_inmates end class Incidents has_many :incidents_inmates has_many :incidents_staff end class IncidentsInmates belongs_to :incident belongs_to :inmate end class IncidentsStaff belongs_to :incident belongs_to :staff end -- doug-jGAhs73c5XxeoWH0uzbU5w@public.gmane.org
Colin Fleming
2005-Aug-19 02:25 UTC
Re: Ternary and attributed relationships in AR (Was: Catalyst/Rails)
On 18/08/05, Zed A. Shaw <zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org> wrote:> Now this should work perfectly. Not really clear how you actually know that the > attributes aren''t part of the objects retrieved this way, but I''ll try that out and see > how it works.I''m doing this in my project, it works well. But you have to be careful adding a bunch of associations-with-attributes to new models - AR can get very confused and screw up the attributes. Make sure you save the model before adding the associations. Cheers, Colin
I don''t understand why it seems necessary that if a project has substantially MORE ability in the control department, people seem to think that it necessitates giving up simplicity. Why can''t we create a framework with ALL of the control as and when we need it - so that we have all of the functionality, but most of it turned off at the beginning, and as and when people get more into the control and power aspect of the framework, they can turn on those features. Julian. On 18/08/2005, at 8:28 AM, Philip Edelbrock wrote:> > > Todd Grimason wrote: > >> [deleted original post by accident] >> http://dev.catalyst.perl.org/wiki/VersusRails >> Hmm, I don''t know, I think it''s pretty fair and accurate. >> I can imagine some people getting all uppity in their seats though >> when >> they hit the last row, the "best suited for" line on Rails: >> """ >> Web-focused fresh (non-legacy) projects with simple-to-moderate data >> model requirements. Due to the simplistic nature of Rails, the >> framework >> has certain limitations that can cause headaches later for more >> complex >> projects. Rails is criticized as being overhyped and branding/ >> marketing >> mostly old ideas as new. >> """ >> > > Humm, I agree. How would you put it? > > For context, the Catalyst side is: > > "More complex projects that need to draw from a larger library and > developer base. Due to the nature of more control and flexibility, > project code can be more complex. Catalyst is criticized as playing > catch-up to Rails, and for not having as complete documentation or > presence. Catalyst has a steeper learning curve than Rails." > > > Phil > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On 8/23/05, Julian Leviston <julian-AfxEtdRqmE/tt0EhB6fy4g@public.gmane.org> wrote:> Why can''t we create a framework with ALL of the control as and when > we need it - so that we have all of the functionality, but most of it > turned off at the beginning, and as and when people get more into the > control and power aspect of the framework, they can turn on those > features.You mean like Rails? :-) If you want more "control" than what Rails provides by default, it''s not that difficult to adapt the framework to meet your needs. -- Regards, John Wilger ----------- Alice came to a fork in the road. "Which road do I take?" she asked. "Where do you want to go?" responded the Cheshire cat. "I don''t know," Alice answered. "Then," said the cat, "it doesn''t matter." - Lewis Carrol, Alice in Wonderland
Just out of interest, How do we do 1:1 relationships in Rails? Julian. On 18/08/2005, at 10:02 AM, Nicholas Seckar wrote:> Todd Grimason wrote: > >> I can imagine some people getting all uppity in their seats though >> when >> they hit the last row, the "best suited for" line on Rails: >> > > Yea. People tend to get uppity when you feed them bs. > > No but really, I''m dying to see one of these complex model setups > that impossible in Rails. > > I''m serious. Let''s hear them. > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Julian Leviston
2005-Aug-24 04:55 UTC
Re: Ternary and attributed relationships in AR (Was: Catalyst/Rails)
I think (and I may be VERY VERY wrong) that if you have to do this, you''ve modelled it in an odd way. Would you not say: There are *STAFF* There are *INMATES* There are *INCIDENTS* : many to many to both *STAFF* and *INMATES*. There are Involvements - which may have many incidents in it. Isn''t it that simple? Isn''t it the case that ALL instances such as this can be resolved down to variations of single and multiple relationships? Even if it''s not that simple, Then you would just want a many-to-many connection to all three of staff, inmates and incidents coming from the involvements class. Right? This doesn''t work? Julian. On 18/08/2005, at 1:28 PM, Zed A. Shaw wrote:> Hi, > > This isn''t a confrontational argument, but more of a demonstration > of two things that I''ve found difficult in AR. I actually asked > this on IRC before reading this thread and didn''t get a response > there. I''m interested in how this would be solved in AR and not in > how AR sucks (take that to a Java list or something). > > TERNARY RELATIONSHIPS > > The application I''m working on is a prison Incident Reporting > System. Yes, it''s a real system, and yes we''re using Rails for it. > > In our first cut of the system we had three objects: Staff, > Inmate, and Incident. I abandonded this model though because, in > order to model the "involved in" it would require a ternary > relationship that connected Staff, Inmate, and Incident together > and I couldn''t get it to work. > > For example: I have the tables staff, inmates, incidents. I need > a single incidents_staff_inmates table (which we originally called > "involvement" but still didn''t help). In addition this relation > needs to be M:M:M (an involvement has many staff, inmates, and > incidents potentially), but the incident could be relaxed to a > single one. > > While the standard response to this is "don''t do that, what you > should do is..." it doesn''t respond to the problem that there''s no > clear way to model this kind of ternary relationship in AR (that I > know of). Also, this shows up quite frequently in practice and is > something that many frameworks just don''t model well, so not only > AR would be lacking. > > ATTRIBUTED RELATIONS > > We dropped the idea of the ternary relationship and instead > generalized Inmate and Staff to Person. This got rid of the > ternary relationship (and is about the only nice way to do this) > and we just use a flag to determine if a person is an Inmate or > Staff. But, then the "attributed relation" problem popped up. As > before, I have an Incident, it has many People invovled, and that''s > done with a HABTM of incidents_people. Pretty simple so far, > nothing too bad. Person.incidents and Incident.people all there. > > Now, each person''s involvement has a set of attributes for the type > of injury they sustained, and how they sustained it. Thus, the > best place to attach this injury_type and injury_cause is on the > incidents_people relationship, since it is basically an attribute > of this relationship between each person and their incident. > Normally, I would just add two extra columns to this relation table. > > Before you think I can put this on Incident, remember this is each > Person''s involvement, so there''s one set of extra attributes for > each Person:Incident connection. > > Any ideas? Hopefully throwing rocks at the straw man will get > other people to do my dirty work. Dance monkeys! > > And, I appreciate the help too. > > Zed A. Shaw > http://www.zedshaw.com/ > > On Wed, 17 Aug 2005 21:47:56 -0400 > Nicholas Seckar <nseckar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > >> For the record, my straw man is still waiting for an complex model >> situtation that spawns headaches when attempted using AR. Complaining >> over the exact use of words doesn''t constitute a refution to me. >> > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
> Just out of interest, > > How do we do 1:1 relationships in Rails?CreditCard belongs_to :account Account has_one :credit_card -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework