I agree, but there are a couple of issues with that. One is that the flag would be so deep and obscured from the actual function of it that it would be most magical. The flag is already one level deeper than I'd prefer it to be. My design chops are pretty fair and this is the best dress we can put on the pig. Second is that this database is not my design, nor the application, and with 1000's of lines of code that go in some pretty intense reporting, changing the structure in a way that would satisfy the client's request elegantly would far outstrip any budget that is allotted for the current iteration. If you'd really like a rundown on the problem and our solution we can share screens on Skype and I'll convince you that the solution is the cleanest, given budget and requirement. Though application design isn't really the question.
The 'is' prefix and its ilk for a bool field or function has been working for me for 20 years and around 9 languages. I love Ruby and Rails, but given that wisdom is having the experience to recognize a mistake as you're about to make it again, I'll reserve the right to adopt what is arguably better and ignore that which is not. That said, and a bit exhausted from defending the irrelevant...how's 'bout that question? On Dec 3, 4:00 pm, Marnen Laibow-Koser <[email protected]> wrote: > Ray Parker wrote in post #966033: > > > I have an Account Model. It has a polymorphic association to an > > Address model. The Address model validates on what you'd expect, and > > the the issue comes about in the order of models and validations. > > > We are trying to wedge functionality into an existing design without > > breaking a large system. > > How's your test coverage? If it's decent, you shouldn't need to worry > about breaking the system, or about "wedging in" functionality. > > (The idea of "wedging in" functionality is itself scary. If something > is worth doing, it's usually worth doing right, with all the refactoring > that that implies.) > > > The new requirement is that the address is > > only validated if a boolean column (is_admin_account) is false. > > And which table is that field in? > > (Style note: it's more Rubyish to leave the "is_" off the names of > booleans.) > > > > > Where I'm running into issue is that the Address model validates > > before the values are updated in the Account model and, based on the > > bool value, I want to validate or not. > > So you want to validate the address, or not, depending on the contents > of a field in an associated record in a different table? That sounds > really, really smelly to me. I suspect it might be worth moving the > validation flag into the addresses table. > > If you can explain more about the structure of your data, I can probably > be more helpful. > > Best, > -- > Marnen Laibow-Koserhttp://www.marnen.org > [email protected] > > -- > Posted viahttp://www.ruby-forum.com/. -- 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
