Hi all,
I have two tables:
TABLE 1
A pk - fk (referencesc TABLE 2)
B pk
C pk
D pk
E
F
TABLE 2
A pk
G
H
I
L
I don’t use incremental field (id). I’d like don’t use find_by_sql.
How can I define both models to use correctly find method (with
include)? With only one column primary key I haven’t problems.
I thought two solutions, but I don’t like these very much (especially
the second):
- modify TABLE 1 (add field id as primary key and define A,B,C,D as
unique) and TABLE 2 (column A reference to field id of TABLE 1)
- I use DB web interface only read mode (users cannot write and
update) and then I can pretend (in model) that TABLE 1 primary key
were only column A
Can you help me?
Thank you very much
engamocap
On 9 Mar 2009, at 11:09, engamocap wrote:
E
How can I define both models to use correctly find method (with
include)? With only one column primary key I haven’t problems.
I thought two solutions, but I don’t like these very much (especially
the second):
There (at least used to be) a plugin that added composite primary key
support to rails. I don’t remember what it was called (never used it
myself) but you might be able to track it down.
Fred
On Mon, Mar 9, 2009 at 6:48 AM, Frederick C.
<[email protected]
wrote:
A pk - fk (referencesc TABLE 2)
I
myself) but you might be able to track it down.
Thank you very much
engamocap
Fred, I believe that you’re talking about the following:
http://compositekeys.rubyforge.org/
-Conrad
compositeprimarykeys is located at:
http://compositekeys.rubyforge.org/
I used an older version of the gem through several rails upgrades (1.2
→ 2.0 → 2.1 → 2.2) and each time things broke, requiring some
monkeypatches, but it looks like the gem has been updated to support
rails 2.2.2 now.
I’d recommend against using multi-column primary keys in general,
however. The gem made use of activerecord internals and that’s
somewhat of a moving target.
Looking at my monkeypatches, the gem used (at least) the internal
active record methods interpolate_sql_options!() and add_joins().
Either the api for those methods changed or they were moved or
removed.
The same thing may happen with the upgrade to 2.3 and/or 3.0. Luckily,
I won’t have to deal with that because we just yanked the
multi-column-primary keys from the schema, making it more rails-y.
Makes life easier.
On Mon, Mar 9, 2009 at 7:48 AM, Frederick C.
[email protected] wrote:
A pk - fk (referencesc TABLE 2)
I
myself) but you might be able to track it down.
Thank you very much
engamocap
–
Steven H. [email protected]
http://www.mshiltonj.com/
http://www.tothware.com/