On Thursday, 16 May 2013 16:44:20 UTC-4, Ruby-Forum.com User wrote:
>
> My experimental application where i use shared primary/foreign key is
> still in experimental phase. It mostly works, but i had to use
> workarounds for saving/updating objects associated through shared
> primary/foreign
My experimental application where i use shared primary/foreign key is
still in experimental phase. It mostly works, but i had to use
workarounds for saving/updating objects associated through shared
primary/foreign key (i do not want to look trough the details now). I
still think that a natur
I know this is an old thread, but as it seems to have the best advice
I've seen on this subject, I'm going to throw my few cents in here.
I'm strongly leaning in the direction of a shared primary/foreign key
for situations where the parent record is a prerequisite for the child
record. Effecti
Thanks for the explanation, it is interesting that the ":primary_key =>"
option does not have to point to the primary key!
--
Posted via http://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,
It is indeed redundant to have both #set_primary_key and the :primary_keyoption
w/in your
#has_many (or #has_one) calls.
You can safely ignore that aspect of my prior posts :). The real code I
yanked my examples from actually has a table with a primary key named "ID"
(so set_primary_key "ID")
Kendall, thank you for your explanations, especially about migrations.
I removed my other post because i realized that in my situation the
primary key used for the association was in fact "id", so it was a bad
example.
Still, in your example, i do not understand the need for ":primary_key
=>":
To further clarify (and answer one of the questions above):
You must specify the :primary_key option to #has_one (and #has_many) in your
model definition if, and only if, the table of the resource that "owns" the
other record (i.e., the table associated w/the model that contains the
#has_one me
For the situation described in this thread where your Person class's
#has_one :instructor refers to another class (and table) that in fact HAS a
column named "person_id" then there is no need to provide the :primary_key
option, as this is what it will infer by default.
However, in even weirder
I have deleted one of my questions because i was apparently confused.
Anyway, i do not understand the use of :primary_key parameter in has_one
option like in
has_one :something, :primary_key => 'someone_id'
What is it for if the primary key has to be set with set_primary_key =>
'someone_id' ?
Just on more related question (if anyone has time to answer):
if i have set_primary_key 'person_id':
class Instructor < ActiveRecord::Base
set_primary_key 'person_id'
...
end
does it mean that writing
class Person < ActiveRecord::Base
has_one :instructor, :primary_key => 'person_id'
end
A relevant question that i think is appropriate for this thread: can
anybody please explain to me the purpose of primary_key type in context
of migrations:
t.primary_key :person_id
?
The migration
class CreateInstructors < ActiveRecord::Migration
def self.up
create_table :instructors do |t|
On 25 March 2011 17:15, Alexey M. wrote:
>>> It is just so natural to use the same primary key in this situation.
>>
>> Why?
>
> Well, it seems natural to me, and i often trust my senses :).
>
> I have been playing with it in console for a few minutes now and
> observing some fun and weird behavio
Kendall, thank's for your suggestion, it really made "id" and
"person_id" equivalent for instructors and stopped the described above
weird (and fun) behavior.
Also,
p=Person.create
m=p.create_member
i=p.create_instructor
work as expected now with setting identical values for p.id, m.id,
m.person
It appears from your console session you never added the #set_primary_key
macro method call to you Instructor class. I just duplicated your console
session as follows in a test project only *with* the set_primary_key call as
follows:
i = Instructor.create
i.id # => 1
i.person_id # => 1
>> It is just so natural to use the same primary key in this situation.
>
> Why?
Well, it seems natural to me, and i often trust my senses :).
I have been playing with it in console for a few minutes now and
observing some fun and weird behavior:
i = Instructor.create
i.id# => 1
i.person_id
It is certainly "possible" to do what you're describing, and yes, the same
person *could* be both an instructor and a member at the same time.
However, I'll second Colin's suggestion that you just follow the convention
to have a separate id primary key column in both the instructors and members
On 25 March 2011 16:47, Alexey M. wrote:
> Colin, probably my life will be much easier, but much less fun.
Are you sure? Trying to force rails away from its preferred
conventions is rarely fun. Do it the easy way and use the time saved
to indulge in something that is really fun :)
> It is just
Colin, probably my life will be much easier, but much less fun.
It is just so natural to use the same primary key in this situation.
--
Posted via http://www.ruby-forum.com/.
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Talk" group.
To post to th
18 matches
Mail list logo
