3 things that should be part of the main Rails tree:
http://www.redhillconsulting.com.au/rails_plugins.html
Views?
Foreign Key Migratitions I agree with 100%. It says “SQL-92 syntax and
as
such should be compatible with most databases that support foreign-key
constraints”, but that should be tested. It needs to work with the
major
databases that rails supports, MySQL, PostgreSQL, Oracle, SQLite, DB2,
etc.
Having unique constraints and indexes in there too would be great.
Without
these features, you must put native SQL in the migrations, which pretty
much
defeats the purpose.
On Thursday, May 25, 2006, at 11:58 AM, Paul B. wrote:
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails
Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails
I disagree a bit regarding the foreign key plugin. Not everyone wants
or needs such a capability, and one of the criteria for core inclusion
is for the feature to be broadly useful to many users. I’m just not
convinced that the foreign key plugin meets those criteria. The
cascading stylesheet and Js plugins seem to meet that criteria at least.
Of course, I would think that it would be worth asking about that on the
core list.
_Kevin
On May 25, 2006, at 9:39 AM, Kevin O. wrote:
great. Without
Of course, I would think that it would be worth asking about that
on the
core list.
I’d love to see better foreign key support in core. There’s a ticket
that added schema dumper support seven months ago, but nobody has
stepped up with unit tests.
http://dev.rubyonrails.org/ticket/2738
jeremy
I’d love to see better foreign key support in core. There’s a ticket
that added schema dumper support seven months ago, but nobody has
stepped up with unit tests.
I think foreign key support in schema.rb is worthy of core inclusion
too, but someone needs to do all the hard work of making sure the
tests are bulletproof and that we’re good across all the databases.
Make that happen and it makes it in.
David Heinemeier H.
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
I know that there is work that needs to be done in order to make the
plugin
work across all databases, etc., but I’m curious, how could you not need
foreign key support in your application? Do you just not mind the
native
SQL in the migration or are you building an application without foreign
keys? I’m just curious to know what others are doing, because to me,
the
idea of building an application that doesn’t have foreign keys at the DB
level seems insane.
On 25 May 2006 16:39:24 -0000, Kevin O. <
On May 25, 2006, at 1:15 PM, Paul B. wrote:
I know that there is work that needs to be done in order to make
the plugin work across all databases, etc., but I’m curious, how
could you not need foreign key support in your application? Do you
just not mind the native SQL in the migration or are you building
an application without foreign keys? I’m just curious to know what
others are doing, because to me, the idea of building an
application that doesn’t have foreign keys at the DB level seems
insane.
There have been a lot of discussions on this subject, and it comes
down to this:
Two sets of thoughts:
-
Integration DBs are accessed by several apps, and MUST have
lots of inbuilt
DB checking to make sure everyone’s on the same page. -
Application DBs are accessed by a single application. With a
good OO layer
(like ActiveRecord) providing lots of validation in the
application layer,
it’s not as critical.
I original came from the #1 side of the fence. After listening to
many people make
many comments on the subject, weighing them in my own mind and
experience, I’m now
much more comfortable with #2.
I personally believe that as we move (quickly) to web services),
there will be
MANY application DBs, each running a simple application, and speaking
to each
other via web services (hopefully nice simple REST web services)
rather than
through the DB.
–
– Tom M.
If your application is the only access for write/delete operations and
you
wrote your application correctly you don’t need foreign keys at all,
they
just slow down your data access 
On May 25, 2006, at 1:15 PM, Paul B. wrote:
I know that there is work that needs to be done in order to make
the plugin work across all databases, etc., but I’m curious, how
could you not need foreign key support in your application? Do you
just not mind the native SQL in the migration or are you building
an application without foreign keys? I’m just curious to know what
others are doing, because to me, the idea of building an
application that doesn’t have foreign keys at the DB level seems
insane.
Paul, everyone’s using foreign keys in concept, but many choose not
to enforce them and are feeling more pleasure than pain as a result.
That’s intriguing, huh?
jeremy
(for most databases) insert/update will be slowed down, but multi-
table queries will be sped up (cross table foreign key indexes) -
sometimes considerably
On 5/25/06, Paul B. [email protected] wrote:
but I’m curious, how could you not need
foreign key support in your application? Do you just not mind the native
SQL in the migration or are you building an application without foreign
keys?
The foreign keys are still there, just not enforced at the database
level. While uncomfortable for us J2EE (or any monolithic database
types), it really makes a lot of sense with the was SOA / Web Services
are going.
After all, why define your foreign keys in the database and the code
if you don’t need to. Not only is it not DRY, it’s also less flexible
(with the powerful model support ActiveRecord gives).
I agree foreign keys at the DB level are needed as much for application
DBs. I aslo agree we might be seeing more and more applciation DBs.
But I
don’t think integration DBs are going away. Even if you don’t have a
pure
integration DB, you might have an application DB where you occasionally
need
to load data in the back end. It’s easier to use tools that the
database
already provide (like LOAD DATA for MySQL, SQLLoader for Oracle, etc).
This
allows a DBA to take care of it and not have to have a developer build a
specific interface at the application layer for importing the data. For
a
regular data feed, it makes sense to have an application level data
import,
but for ad hoc importing of data from other systems, it’s nice to take
care
of it at the DB level, which is why you need a DBA.
Another reason this is import is if for making rails “Enterprise Ready”.
I
know David’s not really concerned about Rails being mainstream -
http://www.loudthinking.com/arc/000584.html - and I take “mainstream”
and
“enterprise ready” to mean the same thing, which is that non-technical
managers involved with IT are comfortable funding a project to be built
with
Rails. To me this is important, because I think RoR is a great
technology
and I would love to be able to use it in the projects I work on. But if
RoR
isn’t viewed as Enterprise Ready by the masses, it will be harder in a
political sense to be able to use RoR on many projects.
So, my point is that this is one of those things that people could look
at
and say “RoR doesn’t even support foreign keys, it’s not for the
enterprise”. I love to be able to eliminate that argument. It seems
that
David does agree that AR migrations should support foreign keys, so it’s
just a matter of finding the time to do it.
On May 25, 2006, at 1:41 PM, Jodi S. wrote:
(for most databases) insert/update will be slowed down, but multi-
table queries will be sped up (cross table foreign key indexes) -
sometimes considerably
Indexing works as expected whether or not you choose to enforce
foreign key constraints.
jeremy
So, my point is that this is one of those things that people could look at
and say “RoR doesn’t even support foreign keys, it’s not for the
enterprise”. I love to be able to eliminate that argument. It seems that
David does agree that AR migrations should support foreign keys, so it’s
just a matter of finding the time to do it.
I don’t personally care about getting adoption by people who skip
Rails because schema.rb didn’t do foreign keys, but I’m not going to
stand in the way of others who do care about that. So if you feel that
this is important to you, please do find a way to help the effort of
getting support in.
At the same time, I don’t want to get any false hopes inflated by
saying OK to this. I am so most certainly not going to work on it. I
doubt anyone else in the Rails core group is interested in doing the
leg work either. So this support will only come from someone who needs
it himself enough to do the work.
So let’s see that code flowing 
David Heinemeier H.
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
Fair enough. I understand that there are probably plently of other
things
you’d personally rather like to see part of rails and your going to
focus
your efforts on those things. I personally don’t have the time to work
on
this now, but hopefully I will in the near future.
On Thu, May 25, 2006 at 11:58:12AM -0400, Paul B. wrote:
[…]
} Having unique constraints and indexes in there too would be great.
Without
} these features, you must put native SQL in the migrations, which
pretty much
} defeats the purpose.
add_index :table_name, [“column1”, “column2”], :name =>
“arbitrary_index_name”, :unique => true
–Greg
On Thu, May 25, 2006 at 03:33:20PM -0500, Steve L. wrote:
} If your application is the only access for write/delete operations and
you
} wrote your application correctly you don’t need foreign keys at all,
they
} just slow down your data access
Aye, there’s the rub. If we could dependably code correctly then
debuggers
wouldn’t exist.
Foreign keys are about more than just a constraint in the database.
Putting
a foreign key constraint on a database column is an explicit statement
of
an assumption. It prevents you from deleting data on which other data
depends, for example, which is quite valuable. Yes, you can handle it at
the application layer, but that’s where your efficiency argument falls
flat. The database is going to be more efficient at enforcing data
integrity constraints if only because it requires less I/O, and that’s
ignoring the difference between a database running as native code and
interpreted Ruby.
Of course, you can simply forego data integrity constraints entirely.
While
you’re at it, perhaps you’d like to do your own memory management as
well.
Sure, it’s somewhat error prone and it’s been shown to reduce programmer
productivity, but garbage collection is so much less efficient, right?
–Greg
On Thu, May 25, 2006 at 01:31:17PM -0700, Tom M. wrote:
[…]
} Two sets of thoughts:
}
} 1) Integration DBs are accessed by several apps, and MUST have lots
of
} inbuilt DB checking to make sure everyone’s on the same page.
That’s an oversimplification, but we’ll go with it.
} 2) Application DBs are accessed by a single application. With a
good
} OO layer (like ActiveRecord) providing lots of validation in the
} application layer, it’s not as critical.
Not as critical, perhaps. It’s still pretty important.
} I original came from the #1 side of the fence. After listening to
many
} people make many comments on the subject, weighing them in my own mind
} and experience, I’m now much more comfortable with #2.
I spent most of this past year dealing with a vast application database.
There were a couple of frontends, but they all used the same ORM
codebase
to interact with the database. 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.
Programmers inevitably write buggy code. It happens. Through
maintenance,
the code gets less buggy. At this point, Solaris has essentially no bugs
that will corrupt data being written to disk. Likewise, Oracle has
essentially no bugs in its data integrity constraint code. They are
codebases that have been actively improved and maintained for years. The
same is true of PostgreSQL and InnoDB, among others. If you express your
data integrity requirements implicitly in all new Ruby code, you are
reinventing the wheel in an error prone manner. If you express them
explicitly as a database integrity constraints, you are leveraging
well-tested, well-maintained, and well-optimized code.
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?
} I personally believe that as we move (quickly) to web services),
there
} will be MANY application DBs, each running a simple application, and
} speaking to each other via web services (hopefully nice simple REST
web
} services) rather than through the DB.
Web services are only as good as the code implementing them. See above.
} – Tom M.
–Greg
Paul B. wrote:
Foreign Key Migratitions I agree with 100%.
While we’re discussing foreign keys in Rails, have you ever wondered why
ActiveRecord tries to find the foreign key column just by name (eg.
‘post_id’)? Wouldn’t it be more logical that it first queries the table
for metadata, finds foreign keys constraints by itself and, if there
aren’t any, fallbacks to guessing by name?
I don’t think anybody here believes that an application framework should
recreate features of relational databases – yet, we do it?
I’m sorry if i sound stupid. But…
Is it that much of a problem really to add foreign keys to migrations?
Rails already senses on a application level how these tables connect
to eachother using the models. Shouldn’t it be easy to make the
migrate command go over the model files and add the fk elements if it
senses that it’s using a DB that handles it.
I just can’t see how FK’s can hurt. I’ve personally had to use them
and i forsee being forced to use them because sometimes there are
other software (or even hardware as I’ve experienced) needs to use the
same database.
On 5/26/06, Paul B. [email protected] wrote:
enterprise". I love to be able to eliminate that argument. It seems
At the same time, I don’t want to get any false hopes inflated by
http://www.backpackit.com – Personal information manager
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails
–