Hi Kevin,
I too am dealing with a legacy schema, and have found a couple of
tricks to make it easier. There are things that AR cannot do, but you
can work around them using raw SQL, and retain the nice model/view
separation even if you don''t use all the AR features.
First the easy stuff. To change the table name and primary key field:
class MyTable < ActiveRecord::Base
def self.table_name()
"MyOddlyNamedTable"
end
def self.primary_key
"the_one_true_key"
end
end
That will automatically make the associations work properly. You
might find youself needing multiple associations between the same two
table, that''s OK, you can actually alias the associations, as such:
belongs_to :current_contact, :class_name => "UserContact" ,
:foreign_key => ''contact_key''
has_many :old_contacts, :class_name => "UserContact",
:foreign_key => ''user_key''
defines two different relationships between the same two tables.
When using raw SQL, there are two options:
find_by_sql(): uses SQL and returns a list of objects of this class that
meet your criteria.
"connection" represents the ruby DBI connection and
connection.execute
can be used just to fetch a bunch of values. You can than bybass all the
AR magic and just return arrays of values.
You mention using stored procedures. RoR doesn''t handle these
explicitly, and I personally don''t have to deal with them since I
am on MySQL. But there are really two cases here.
1. Your stored procs pretty much work with one table, primarily
2. Your stored procs work with a conceptual entity that doesn''t
really
exist as a single table.
For case one, just set up a normal AR class, and use find_by_sql() to return
AR instances.
For case two, consider setting an AR class that doesn''t directly
represent a
single table or view. Set the table name to something like
''invalid_table'' to
prevent mischief.
Here''s where it gets a bit fuzzy for me. AR uses ruby class magic to
deal
with fields in a table (setting up accessors and what not). I don''t
know what
happens if you end up with two instantiated objects with DIFFERENT field
lists. e.g. InstanceA has
[''index'',''fieldA''] and InstanceB has
[''index'',''fieldB''].
If this is ever going to happen, I use connection.execute instead (just
plan ruby DBI) and then return my values as arrays rather than AR objects.
If you do this you can''t use any of the AR magic, but it allows you to
keep
all you DB logic in a cleanly separated model class.
One more thing that you might not be expecting is that the AR associations
don''t set up joins they way you would think. If you have speed
critical
multiple table queries than find_by_sql is usually much faster. I learned a lot
about AR by tailing my DB query log.
I''d love to hear from anyone who understands what happens when two
different instances end up representing different tables or lists of fields
I wrote this in a hurry, I hope you can pull some sense out of it.
-Lee
On Mon, 7 Mar 2005 08:48:29 -0500, Kevin Davis wrote> I''m looking at using RoR for a system tying in with a legacy DB
that
> can''t be modified (other apps using etc). It uses stored procs
> extensively.
>
> Searching for some kind of a guide / tutorial etc for handling this
> kind of situation I''m only coming up with a bunch of 2 paragraph
> articles saying "RoR is great! but there might be some trouble with
> legacy systems".
>
> I''d like to know about forcing RoR to use explicit table names for
> joins and how to use stored procedures.
>
> Thanks!
>
> Kevin
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
--
Naxos Technology