Forum: Ruby on Rails Make these a prt of Ruby on Rails!

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Matt P (Guest)
on 2006-05-25 18:35
3 things that should be part of the main Rails tree:

http://www.redhillconsulting.com.au/rails_plugins.html

Views?
Paul B. (Guest)
on 2006-05-25 20:00
(Received via mailing list)
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.
Kevin O. (Guest)
on 2006-05-25 20:41
(Received via mailing list)
On Thursday, May 25, 2006, at 11:58 AM, Paul B. wrote:
>>
>> removed_email_address@domain.invalid
>> http://lists.rubyonrails.org/mailman/listinfo/rails
>>
>
>
>_______________________________________________
>Rails mailing list
>removed_email_address@domain.invalid
>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
Jeremy K. (Guest)
on 2006-05-25 21:47
(Received via mailing list)
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
David Heinemeier H. (Guest)
on 2006-05-25 22:56
(Received via mailing 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

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
Paul B. (Guest)
on 2006-05-26 00:20
(Received via mailing list)
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. <
Tom M. (Guest)
on 2006-05-26 00:32
(Received via mailing list)
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:

   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.

   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.

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.
Jeremy K. (Guest)
on 2006-05-26 00:36
(Received via mailing list)
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
Steve L. (Guest)
on 2006-05-26 00:36
(Received via mailing list)
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 ;-)
Jodi S. (Guest)
on 2006-05-26 00:45
(Received via mailing list)
(for most databases) insert/update will be slowed down, but multi-
table queries will be sped up (cross table foreign key indexes) -
sometimes considerably
Curtis S. (Guest)
on 2006-05-26 00:48
(Received via mailing list)
On 5/25/06, Paul B. <removed_email_address@domain.invalid> wrote:
> <snip> 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).
Paul B. (Guest)
on 2006-05-26 00:51
(Received via mailing list)
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.
Jeremy K. (Guest)
on 2006-05-26 01:31
(Received via mailing list)
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
David Heinemeier H. (Guest)
on 2006-05-26 03:13
(Received via mailing list)
> 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
Paul B. (Guest)
on 2006-05-26 05:52
(Received via mailing list)
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.
Gregory S. (Guest)
on 2006-05-26 14:52
(Received via mailing list)
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
Gregory S. (Guest)
on 2006-05-26 15:10
(Received via mailing list)
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
Gregory S. (Guest)
on 2006-05-26 15:26
(Received via mailing list)
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
Jón B. (Guest)
on 2006-05-26 15:41
(Received via mailing list)
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. <removed_email_address@domain.invalid> 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
> removed_email_address@domain.invalid
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
>


--
Mislav (Guest)
on 2006-05-26 16:12
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?
Kevin O. (Guest)
on 2006-05-26 17:17
(Received via mailing list)
>
>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
Kevin O. (Guest)
on 2006-05-26 17:39
(Received via mailing list)
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
>removed_email_address@domain.invalid
>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
Philip H. (Guest)
on 2006-05-26 22:45
(Received via mailing list)
> same database.
Would this help?

Plugins - Foreign Key Migrations - Agile Web D.
http://www.agilewebdevelopment.com/plugins/foreign...
Justin F. (Guest)
on 2006-05-26 23:20
(Received via mailing list)
Philip H. wrote:

> Would this help?
>
> Plugins - Foreign Key Migrations - Agile Web D.
> http://www.agilewebdevelopment.com/plugins/foreign...

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
Tom M. (Guest)
on 2006-05-27 02:41
(Received via mailing list)
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. :-)

> 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. :-)

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.
This topic is locked and can not be replied to.