Michael, If it were me who had created that monstrosity I would have apologized in advance, believe me. :)
Funny enough, I might very probably be on the phone talking to the "owner of the beast" in a few minutes and believe it or not, instead of starting to keep things 'sane' and add additional information in new tables he has already suggested adding a brand new set of 32 columns for the related values we need to store now! :D The sad thing is that the way things are now we might just need to put up with it! This guy is obviously on his way out and the application will be rewritten and the DB redesigned at some point in the near future. The owner of the application is trying to find the "path of least resistance" right now to make things work so we can meet the deadlines we have and start working on the replacement software asap so we don't need have this other person involved any longer. I'll remember to bring my Louisville Slugger if I ever meet him in person. ;) On Feb 23, 3:38 pm, Michael Pavling <pavl...@gmail.com> wrote: > On 23 February 2010 20:20, pepe <p...@betterrpg.com> wrote: > > > Thanks a lot Michael for your explanation and efforts. :) > > > I had thought about going the way you propose but it seemed to me like > > too much work (I think the total amount of columns I would need to > > write code for is 32) for what I actually need. > > The > > Projects table has an ID and also a project code, which is also > > supposed to be unique "when it has a value" (this is enforced at > > application level). The project ID is not what is stored in the > > 'project' columns in the Worker record, it is the project code > > instead. > > Well, the first thing you have to do is creep up behind the original > developer of that table with your Louisville Slugger in hand... > > But seriously, whoever produced that table should be fired. If my > plumber connected the taps that badly I'd get wet every time I change > channel on the TV. [1] > > > If there is an easy > > way of making the association work both ways I surely would like to > > know > > Given your table structure, I think you've done well to get as much > use out of it as you have; your "projects" method is another little > fudge I might have considered. > You might get something else working (both ways with a little hassle) > using named scopes rather than associations; defining them (all 32+!) > in a loop to be DRY, and concatenating their results like I suggested > with the associations. But it's a lot of hard work, and not really > what Rails is best at. > > Honestly, I think you'd be better off spending the time scouring the > job sites for a new employer; somewhere where databases are free to > enjoy the benefits of friendly ORMs :-) > > Good luck, > Michael > > [1] If it was *you* that created the current tables, but "years ago, > before you knew what you were doing".... well, it's fair enough that > you're trying to sort it out now... as long as you're suitably > apologetic ;-) -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-t...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
