Now, what I need to do is relate one of the operator’s pingable_ips
with each of their operator_aps. I’m not sure what the best way to go
about this is, or how to properly define it with the has_many/
belongs_to relationships. I was thinking of just doing:
operator_ap has_one pingable_ip
but then pingable_ip belongs_to both operator and operator_ap, and
operator_ap already belongs_to an operator. Not sure if this will
cause any issues, especially when deleting records from these tables.
If anybody has any advice on a nice way to set these relationships up,
it would be greatly appreciated.
Now, what I need to do is relate one of the operator’s pingable_ips
with each of their operator_aps. I’m not sure what the best way to go
about this is, or how to properly define it with the has_many/
belongs_to relationships. I was thinking of just doing:
operator_ap has_one pingable_ip
but then pingable_ip belongs_to both operator and operator_ap, and
operator_ap already belongs_to an operator. Not sure if this will
cause any issues, especially when deleting records from these tables.
I think it depends on the relationship between pingable_aps and
pingable_ips. If you allocate the ip to the app depending on
whether it is one of the operator’s ip addresses, then break the
association between the operator and the app. You can always tell
the ip address to do things to the apps it owns. Otherwise, if you
allocate the ap depending on whether it is going to the operator’s
app, break the association between the operator and the ip.
Basically, they should not be poking in each other’s pockets so
much. If it is one ip per app, you can always ask the apps to
handle the IP issues.
As a third choice, the operator keeps the mapping between
her apps and her ips, and the two need never know about this
directly.
Circular graphs make recursion too … er, interesting…
If anybody has any advice on a nice way to set these relationships up,
it would be greatly appreciated.
Thanks,
Simon
HTH, though I don't understand your problem domain in detail.
Hugh
>
> operator has_many operator_aps
> operator has_many pingable_ips
>
>
> operator_ap has_one pingable_ip
>
> but then pingable_ip belongs_to both operator and operator_ap, and
> operator_ap already belongs_to an operator. Not sure if this will
> cause any issues, especially when deleting records from these tables.
>
> If anybody has any advice on a nice way to set these relationships up,
> it would be greatly appreciated.
>
> Thanks,
>
> Simon
Simon! (cool to see you on this list)
If I understand you correctly, this is what you have…
class Operator < ActiveRecord::Base
belongs_to :operator_app
has_many :pingable_ips
end
class OperatorApp < ActiveRecord::Base
has_many :operators
has_many :pingable_ips
end
class PingableIp < ActiveRecord::Base
belongs_to :operator_app
belongs_to :operator
end
You should be fine when it comes to destroying records, the thing to
watch for is how you set up your foreign key constraints! (Just watch
for the caveat at the bottom.)
oa = OperatorApp.new
=> #<OperatorApp:0x3466128 @new_record=true, @attributes={}>
oa.pingable_ips.first.operator = oa.operators.first # <- the “circular” reference you are concerned about
=> #<Operator:0x3464224 @new_record=true,
@attributes={“operator_app_id”=>nil}>
That was close to what I meant, but here is what I was trying to get
at:
class Operator < ActiveRecord::Base
has_many :operator_app
has_many :pingable_ips
end
class OperatorApp < ActiveRecord::Base
belongs_to :operators
has_one :pingable_ips
end
class PingableIp < ActiveRecord::Base
belongs_to :operator_app
belongs_to :operator
end
I just don’t like how those relationships are circular, with the
PingableIp belonging to both the Operator and the OperatorApp, when
the OperatorApp also belongs to an Operator. But so far I haven’t
come up with a clever way to handle those relationships differently.
Basically, the Operator has many OperatorApps and PingableIps, and
each single OperatorApp needs to be associated with a single
PingableIp that also belongs to that Operator. The same PingableIp
can be related to several OperatorApps.
Hi,
The API documentation states that belongs_to is used on a model class
when you have foreign keys on the model’s table. So what does your
pingable_ips table look like? The way your PingableIp class is setup now
implies that the pingable_ips table has a operator_app_id and an
operator_id. But the operator_apps table would also have an
operator_id, so it’s actually redundant (I wouldn’t really call it
circular).
Since you don’t need the foreign key, I believe that means you shouldn’t
(and can’t) have the belongs_to :operator in your PingableIp. In your
Operator class, you can put has_many :pingable_ips, :through =>
:operator_app.
(It’s like the Firm/Client/Invoice example in the “Association Join
Models” section of the ActiveRecord::Assocations::ClassMethods
documentation. See ActiveRecord::Associations::ClassMethods)
That was close to what I meant, but here is what I was trying to get
at:
class Operator < ActiveRecord::Base
has_many :operator_app
has_many :pingable_ips
end
class OperatorApp < ActiveRecord::Base
belongs_to :operators
has_one :pingable_ips
end
class PingableIp < ActiveRecord::Base
belongs_to :operator_app
belongs_to :operator
end
I just don’t like how those relationships are circular, with the
PingableIp belonging to both the Operator and the OperatorApp, when
the OperatorApp also belongs to an Operator. But so far I haven’t
come up with a clever way to handle those relationships differently.
Basically, the Operator has many OperatorApps and PingableIps, and
each single OperatorApp needs to be associated with a single
PingableIp that also belongs to that Operator. The same PingableIp
can be related to several OperatorApps.
Maybe I’m missing something obvious, or just thinking about the
relationships the wrong way, but there must be a cleaner way to get
this set up.