|
Joe--still smiling, said it in the last one, so will stick to informing about the technology here
Actually, one of the complaints I've read about Rails is that it doesn't understand foreign keys very well. I tried to understand why not; as far as I can tell DHH insists that since he can't tell whether a foreign key relationship is 1-1, 1-N or N-N, then he isn't going to do any of them. This seems to me an odd concept for a convention-based language, but he runs the ship.
What he's said is that he'll leave this to the developer to do, as they know what they are facing and want. You have to pick the things you want to make magic carefully. In other words, there's very little difference between 1-1 and 1-N, and if it's N-N, you need an intersection table, so you'll create it, if you're serious.
Also, if your tables aren't named the way Rails like them (the name of a table is plural, such as customers) and your columns aren't named the way Rails wants them (a link to the customers table must be called customer_id), then you lose much of RoR's ability to do things for you. That's the downside of "coding by convention".
Restated from a positive view, if you fight the way Rails works, you lose some of the goodness. But you can do so in order to adapt to legacy tables you can't change, if you must, though most people don't need to often. And the goodness is the upside of coding by convention.
I am particularly not fond of the table naming silliness. What if I have a list of octopi. Do I have to call the table octopuss? <grin>
Rails knows about English pluralization, so it can handle things like this. Not sure if this extends to octopus/octopi, but if you have a list of octopi, it probably ought be abstracted to a higher level and called animals with a type of octopus so you'll be able to widen your scope later. ;D
And please, remember, I am NOT downing RoR.
*cough* *cough* what? male bovine excrement.
Both Ruby and Rails are examples of excellent programming done by exceptionally talented people. I'm just trying to keep the hype to a minimum so that we find out just how good these tools are WITHOUT having to fend off the fanatics. I'll be happy to face the wrath of the Inquisition if in the end it provides the impetus for an honest appraisal of the tools.
Let's hear some discussion of baked in tests, test-driven design, database migrations, etc.
--Jerome Learn, baby, learn, it's the zealot's inferno...
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
