Forum: Ruby on Rails What does has_one :through get me?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Brian (Guest)
on 2009-05-20 09:48
(Received via mailing list)
Apparently I assumed functionality that doesn't exist for this
association.  Should I not be able to reference the target model as an
attribute?

Here are my models:

class User < ActiveRecord::Base
  has_one :membership
  has_one :role, :through => :membership
end

class Membership < ActiveRecord::Base
  belongs_to :user
  belongs_to :role
end

class Role < ActiveRecord::Base
end

But, the "role" attribute for an instance of User always contains nil:

>> user = User.new
=> #<User id: nil, created_at: nil, updated_at: nil>
>> user.save!
=> true
>> membership = user.create_membership
=> #<Membership id: 1, user_id: 1, role_id: nil, created_at:
"2009-05-20 05:40:1
7", updated_at: "2009-05-20 05:40:17">
>> role = membership.create_role
=> #<Role id: 1, created_at: "2009-05-20 05:40:33", updated_at:
"2009-05-20 05:4
0:33">
>> user.membership
=> #<Membership id: 1, user_id: 1, role_id: 1, created_at: "2009-05-20
05:40:17"
, updated_at: "2009-05-20 05:40:17">
>> user.membership.role
=> #<Role id: 1, created_at: "2009-05-20 05:40:33", updated_at:
"2009-05-20 05:4
0:33">
>> user.role
=> nil
>> quit

Why does user.membership.role contain a record, but user.role does not?
Marnen L. (Guest)
on 2009-05-20 10:02
Brian wrote:
[...]
> class User < ActiveRecord::Base
>   has_one :membership
>   has_one :role, :through => :membership
> end
>
> class Membership < ActiveRecord::Base
>   belongs_to :user
>   belongs_to :role
> end
>
> class Role < ActiveRecord::Base
> end
[...]

I don't know if this is the problem, but I think you forgot Role
has_many :memberships.

I'll admit, though, that in this case I don't really see that the
Membership model is any use.  Why aren't you just connecting User and
Role directly?

Best,
--
Marnen Laibow-Koser
removed_email_address@domain.invalid
http://www.marnen.org
Manasi V. (Guest)
on 2009-05-20 16:02
Brian wrote:
> Apparently I assumed functionality that doesn't exist for this
> association.  Should I not be able to reference the target model as an
> attribute?
>
> Here are my models:
>
> class User < ActiveRecord::Base
>   has_one :membership
>   has_one :role, :through => :membership
> end
>
> class Membership < ActiveRecord::Base
>   belongs_to :user
>   belongs_to :role
> end
>
> class Role < ActiveRecord::Base
> end
>
>

Hi Brian,
I think even if it is has_one: through or has_many :through, you should
define -
class User < ActiveRecord::Base
   has_many :membership
   has_one :role, :through => :membership
 end

when defining user and membership. Then try user.role
I have worked on has_many :through recently. My example -
http://manasivora.blogspot.com

Let me know if it helps -

Thanks,
Manasi
Brian (Guest)
on 2009-05-20 21:46
(Received via mailing list)
On May 20, 8:02 am, Manasi V. <removed_email_address@domain.invalid>
wrote:
> Hi Brian,
> I think even if it is has_one: through or has_many :through, you should
> define -
> class User < ActiveRecord::Base
>    has_many :membership
>    has_one :role, :through => :membership
>  end
>
> when defining user and membership. Then try user.role

Thanks for the tip, Manasi.  This didn't solve the problem.  After
defining them as you suggest I do the following:
    user = User.new
    user.save!
    membership = user.memberships.create
    role = membership.create_role

And then in the debugger:
(rdb:1) user
#<User id: 1, created_at: "2009-05-20 17:34:08", updated_at:
"2009-05-20 17:34:0
8">
(rdb:1) user.memberships.find(:first)
#<Membership id: 996332878, user_id: 1, role_id: nil, created_at:
"2009-05-20 17
:34:08", updated_at: "2009-05-20 17:34:08">
(rdb:1) membership
#<Membership id: 996332878, user_id: 1, role_id: 1, created_at:
"2009-05-20 17:3
4:08", updated_at: "2009-05-20 17:34:08">
(rdb:1) membership.role
#<Role id: 1, created_at: "2009-05-20 17:34:08", updated_at:
"2009-05-20 17:34:0
8">
(rdb:1) user.role
nil

Now the interesting thing is that user.memberships.find(:first) has no
role_id, but membership does.  I'm not sure what this means, but I'll
explore it further.  I suspect my problem might be cached records,
but:

(rdb:1) user.memberships(true).find(:first)
#<Membership id: 996332878, user_id: 1, role_id: nil, created_at:
"2009-05-20 17
:34:08", updated_at: "2009-05-20 17:34:08">

I thought the 'true' caused this to be reloaded, so I don't have an
explanation for the discrepency.

I'm a little relieved this didn't work, since the combination of
has_many memberships and has_one role doesn't make sense to me.
Brian (Guest)
on 2009-05-20 21:56
(Received via mailing list)
On May 20, 2:02 am, Marnen Laibow-Koser <rails-mailing-l...@andreas-
s.net> wrote:
> I don't know if this is the problem, but I think you forgot Role
> has_many :memberships.
>

I don't think methods on the Role class should affect this in anyway.
I should only define the association if I benefit from the methods it
provides, right?  Or are there other effects I should be aware of?

Anyways, I gave this a try and the results are the same.

> I'll admit, though, that in this case I don't really see that the
> Membership model is any use.  Why aren't you just connecting User and
> Role directly?

Fair question.

You're probably right that this should be redesigned.  The reasons I
ended up with this are:
 1) Originally I had planned to have a has_many relationship between
user and role. When my plan changed I was lazy and didn't change
models/schema.
 2) Personal taste. I don't like to have empty fields in my database
by design.  If a record exists, all of the fields should have a
value.  This design lets a user have 0 or 1 roles and I test for this
by looking for the existance of a record in the join table.  I don't
know why this bothers me and it's probably irrational.  :)
 3) The example is somewhat contrived, though it does mimic an
application I'm writing.  I left out all of the fields for these
tables except the IDs so that I could demostrate the problem here.
Brian (Guest)
on 2009-05-21 00:23
(Received via mailing list)
Now I'm especially stumped.  I rewrote this as a has_many :through:

class User < ActiveRecord::Base
  has_many :memberships
  has_many :roles, :through => :memberships
end

class Membership < ActiveRecord::Base
  belongs_to :user
  belongs_to :role
end

class Role < ActiveRecord::Base
  has_many :memberships
end

But when I create a user, membership, and role, I still cannot access
role through user:

    user = User.new
    user.save!
    membership = user.memberships.create
    role = membership.create_role

When I look at the value of user.roles(true) I get an empty array.

Obviously I'm doing something very wrong.
Matt J. (Guest)
on 2009-05-21 06:18
(Received via mailing list)
This may be a dumb question, but what version of Rails are you on? I
know that versions earlier than 2.2.2 had some difficulties with
has_one :through...
Brian (Guest)
on 2009-05-21 06:36
(Received via mailing list)
On May 20, 10:17 pm, Matt J. <removed_email_address@domain.invalid> wrote:
> This may be a dumb question, but what version of Rails are you on? I
> know that versions earlier than 2.2.2 had some difficulties with
> has_one :through...
>

Yeah, I was looking at some related bug fixes, but I think they are
all incorporated.  I'm using 2.3.2.  There are a couple things I'll
try later tonight when I have a chance to look again:

First, the debugger is giving me something strange in the
AssociationProxy class in the reload method.  After calling reset (it
uses AssociationCollection#reset) @loaded == true according to the
debugger.  If loaded really is true, it might expliain this, but I'm
still under the assumption that I'm misinterpreting the debugger, or
the debugger is wrong, because otherwise I misunderstand inheritance
in ruby and there's a bug in rails (this seems less likely).  I
haven't been able to duplicate this with a smaller repro, but I'll try
again tonight.

Second, I think it's very likely that my scenario isn't all that
common. And it's very likely that the association implementation
wasn't designed with this in mind.  I'm running into this in a unit
test.  Instead of creating models in memory, I'll load up data from
the test DB, and I'm guessing user.roles suddenly starts working.
Then at least I know I can work around the problem with test fixtures.

In the meantime, if anyone else has an idea of what's going on, let me
know.
Brian (Guest)
on 2009-05-21 07:40
(Received via mailing list)
To follow-up, this works fine with test fixtures.  It also works fine
if I do things in a slightly different order:

user=User.new
user.build_membership
user.membership.build_role
user.save!

When I do this, user.role no longer returns nil, it returns the role
as expected.  I think things weren't cached quite right, and for
whatever reason I couldn't force a proper reload.  Maybe a bug in
rails?
Manasi V. (Guest)
on 2009-05-21 22:20
Hi Brian..
Glad that you could figure out the solution !! .. In my earlier reply
what I meant was that for defining has_many :through, you need to
declare -
has_many :memberships
has_many :roles, :through => memberships

Please note that has_many :Pluralised model needs to be established.
Then you may define has_many through or has_one through..

Also when you say debugger, are you referring to ruby console ? I work a
lot on the console and have never come across any caching issue. Try it
if you would like -
ruby script/console

Cheers,
Manasi
Matt J. (Guest)
on 2009-05-21 23:39
(Received via mailing list)
Yep, working with AssociationProxy stuff in either the debugger or the
console is nasty. Things have a tendency to happen without being told
to (especially loading the target).

Also, have you tried calling membership.save in your original example?
The code you show will set the FK in membership (via
membership.create_role), but it's not on the DB until you save it...

--Matt J.
Brian (Guest)
on 2009-05-22 01:03
(Received via mailing list)
Yes, I figured out what you meant in your original mail.  Even when I
used has_many I wasn't able to get anything useful from user.roles.

By debugger I mean the ruby-debug gem, though I've also used the
console for a lot of this too.

On May 21, 2:20 pm, Manasi V. <removed_email_address@domain.invalid>
Brian (Guest)
on 2009-05-22 01:07
(Received via mailing list)
On May 21, 3:38 pm, Matt J. <removed_email_address@domain.invalid> wrote:
> Also, have you tried calling membership.save in your original example?
> The code you show will set the FK in membership (via
> membership.create_role), but it's not on the DB until you save it...
>
> --Matt J.
>

This lead me to believe otherwise:
http://guides.rubyonrails.org/association_basics.h...

Specifically, "The create_association method returns a new object of
the associated type. This object will be instantiated from the passed
attributes, and the link through its foreign key will be set. In
addition, the associated object will be saved (assuming that it passes
any validations)."

Is the guide wrong about this being saved?  In any case, I actually
did try this with the build_association followed by a .save! and got
exactly the same results.
Matt J. (Guest)
on 2009-05-23 01:47
(Received via mailing list)
What you're describing would look like:

membership.build_role.save!

What I'm talking about is:

membership.create_role
membership.save

--Matt J.
This topic is locked and can not be replied to.