Make these a prt of Ruby on Rails!

Rails
21

On Friday, May 26, 2006, at 2:12 PM, Mislav wrote:

recreate features of relational databases – yet, we do it?

–
Posted via http://www.ruby-forum.com/.

Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails

Why query the database for metadata if you already know that the fk is?
If you follow convention, then you can just use it rather than having to
look it up every time.

_Kevin

22

Ask yourself whether it is more likely that you have a bug in the code
you’ve written over the last week or that there is a bug in your RDBMS’s
integrity constraint enforcement. Which would you rather rely on for your
mission-critical data?

–Greg

Good points, however…
With the current state of the rails codebase, I am probably as likely to
introduce a bug into the migration specifying the FK relation as I am to
mis-use it in a model. Specifying the contstraints instead of relying
on conventions is simply another potential source of bugs.

_Kevin

23

Philip H. wrote:

Would this help?

Plugins - Foreign Key Migrations - Agile Web D.
http://www.agilewebdevelopment.com/plugins/foreign_key_migrations

That’s where the thread started! Matt P wrote:

| 3 things that should be part of the main Rails tree:
|
| http://www.redhillconsulting.com.au/rails_plugins.html
|
| Views?

regards

Justin

24

same database.
Would this help?

Plugins - Foreign Key Migrations - Agile Web D.
http://www.agilewebdevelopment.com/plugins/foreign_key_migrations

25

On May 26, 2006, at 4:24 AM, Gregory S. wrote:

I spent most of this past year dealing with a vast application
database.

Well, perhaps it should have been many small DBs. :slight_smile:

There were a couple of frontends, but they all used the same ORM
codebase
to interact with the database.

Couple of frontends? Sounds like an integration DB to me.

There were no data integrity constraints in the database, but this
ORM did
a pretty good job of dealing with it.

It didn’t do a good enough job, however. The database was full of
bad
data, dirty data, data that should never have made it into the
database and
that would have been caught by decent data integrity constraints.

Well, hate to break it to you, but I’ve worked on integration DBs
with tons
of constraints that were full of bad, dirty data that should never
have made
it into the DB. :slight_smile:

We’re not really in disagreement. If you read my previous posts, you
already
know that.

Bugs are bugs are bugs. Specifying constraints in the DB doesn’t
prevent bugs,
because the constraints themselves can have be buggy too.

Again, as I mentioned previously, I came from your side of the
argument.

I haven’t lost my mind (yet) or gone senile, but I did approach the
question
with an open mind, as I’m sure you are as well.

–
– Tom M.