Hey Dani,
I haven't actually read any of the Rails recipes books, so I can't
comment on this exactly, but I think I get what you're saying/asking.
When you use ActiveRecord, the database abstraction and modeling
system in Rails, it has a method called "execute" that you can call
by:
ActiveRecord::Base.connection.execute("your sql statement here")
The thing is that you have to supply a FULL SQL statement to the
execute method. This is the exact same thing as connecting to the
database directly and issuing the statement "by hand". The problem is
that doing this will require you to write the SQL statement in
whatever syntax your particular database of choice is using. So if
you're developing on MySQL and you want to deploy using PostgreSQL,
for example, you'll end up writing your SQL statement inside the
execute method using a MySQL "flavored" statement that may not work
later on if you deploy using PostgreSQL.
The other problem is that when you deploy an application in
production, while you CAN use database migrations to create the data
structure, it's generally not recommended because it can be a lot
slower than having Rails use its schema.rb file. Every time you run a
database migration, Rails automatically updates this file (schema.rb)
to reflect the CURRENT state of your database's structure. This way,
when it's time to deploy, you can just do rake db:setup
RAILS_ENV=production and Rails will read the schema.rb file and make
the database structure match what's in it.
The problem is, as Marnen points out (I'm just elaborating here to
help you learn a bit more), that because Rails doesn't have any built
in support for database level foreign keys, it'll never put this
information in schema.rb. So when you go to deploy your application,
without foreigner, it won't know to actually add the foreign keys
since it's not running the migrations.
You might think, "well that's simple, just deploy using rake db:create
and then rake db:migrate". Even if you did it this way, you could
still run into problems if you wrote your SQL for adding the foreign
key based on the syntax of one database, and you're deploying on
another.
This is why foreigner is so useful. It adds all the "awesomeness"
needed to make adding foreign keys database-agnostic (develop on one,
deploy on another) and adds this capability to schema.rb, and helps
Rails keep track of it all.
I hope this helps you wrap your head around it some more! Good luck!
On Nov 21, 1:50 pm, Dani Dani <li...@ruby-forum.com> wrote:
> Marnen Laibow-Koser wrote in post #962137:
>
> > Working without foreign key constraints is playing with fire. It may
> > look like it is working, but you'll be setting yourself up for subtle
> > bugs that may not be immediately obvious but will cause you no end of
> > grief when they occur. Don't ever do that.
>
> > Moral: if you care about the integrity of your data, you need physical
> > constraints in the DB to ensure that integrity. If you don't care about
> > that integrity, don't waste time storing the data. :)
>
> Hi,
>
> In reference to the above, I happen to come across the "Advanced Rails
> Recipes" book from Mike Clark. Recipe Nr. 8 in the book is called "Add
> Foreign Key Constraints", explaining how to add foreign key constaraints
> to the database to ensure referntial integrity using the 'execute'
> method. I assume this would then be sufficient to prevent manual doings
> directly in the DB. Any experience with this ?.
>
> Regards,
> Dani
>
> --
> 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 rubyonrails-t...@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
