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