What is the purpose of :conditions on a belongs_to association?

Say I have the following association with an attached condition:

belongs_to :admin_user,
    :class_name => 'User',
    :foreign_key => :admin_user_id,
    :conditions=> 'users.admin=TRUE' # or any variation with hash or

array, {:admin => true}, etc.

The API
stateshttp://api.rubyonrails.org/classes/ActiveRecord/Associations/ClassMethods.html#M001835that
the :conditions option on belongs_to will:

Specify the conditions that the associated object must meet in order to
be

included as a WHERE SQL fragment, such as authorized = 1.

But the output shows no WHERE clause on the select, and in any case I
would
expect that conditions like this on a belongs_to would prevent
persisting
that relationship to begin with, on the INSERT not the SELECT. This
option
seems to have no effect on a belongs_to association, unless I’m missing
something. The option makes sense on a has_many, I just don’t see how it
applies to belongs_to.

I’ve posted this on
stackoverflowhttp://stackoverflow.com/questions/2156514/what-is-the-purpose-of-conditions-on-a-belongs-to-associationas
well, just fyi.

Thanks,
Dave


And all the Knave e’er wanted was his rug
As spoken of, which tied the room together.

Dave S. wrote:

But the output shows no WHERE clause on the select, and in any case I
would
expect that conditions like this on a belongs_to would prevent
persisting
that relationship to begin with, on the INSERT not the SELECT. This
option
seems to have no effect on a belongs_to association, unless I’m missing
something. The option makes sense on a has_many, I just don’t see how it
applies to belongs_to.

Take this contrived example:

Department
has_many :people
end

Person
belongs_to :department, :conditions => { :name => “Development” }
end

person # assume this exists
person.department.name
=> “Development”
department # assume this exists
department.name
=> “Marketing”
person.department = department
person.save
person.reload
person.department
=> nil

SELECT * FROM “departments” WHERE (“departments”.“id” = 1 AND
(“departments”.“name” = ‘Development’))

Upon further inspection I do see that the condition will restrict the *
retrieval* of items (and even then only after they are reloaded), but
not
the persistence. I can assign an invalid object (invalid according to
the
condition) and that reference is persisted to the database upon save.
The
invalid attribute will be available on that object in memory until the
object is reloaded.

On Thu, Jan 28, 2010 at 2:00 PM, Robert W. [email protected]
wrote:

person # assume this exists

[email protected][email protected]
.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.


And all the Knave e’er wanted was his rug
As spoken of, which tied the room together.

If you know of documentation in addition to the api docs linked from my
original post which might be helpful, feel free to include a link.

On Thu, Jan 28, 2010 at 3:47 PM, Chris Drappier
[email protected]wrote:

something. The option makes sense on a has_many, I just don’t see how
belongs_to :department, :conditions => { :name => “Development” }
person.reload
“Ruby on Rails: Talk” group.

.
Office : 256-830-4811 x114
http://groups.google.com/group/rubyonrails-talk?hl=en.


And all the Knave e’er wanted was his rug
As spoken of, which tied the room together.

Dave S. wrote:

If you know of documentation in addition to the api docs linked from my
original post which might be helpful, feel free to include a link.

As mentioned, the API doc actually does explain this relatively clearly
in this statement:

:conditions
Specify the conditions that the associated object must meet in order
to be included
as a WHERE SQL fragment, such as authorized = 1.

The :conditions option applies to the associated object as a WHERE SQL
fragment. There is no mention of any validation, or referential
integrity. Rather it is a “filter” on the association. It simply
determines whether or not the referenced object is returned.

If you need validation of the association, then use validation.
ActiveRecord provides reasonably extensive validation support. That,
along with database referential integrity, is the right place for
ensuring validity.

read the documentation on this. it explains it pretty thoroughly.

On Thu, Jan 28, 2010 at 3:40 PM, Dave S. [email protected] wrote:

But the output shows no WHERE clause on the select, and in any case I

=> “Development”
(“departments”.“name” = ‘Development’))
For more options, visit this group at

You received this message because you are subscribed to the Google G.
“Ruby on Rails: Talk” group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected][email protected]
.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.


Chris Drappier
Software Developer
Analytical Mechanics Associates, INC.
Office : 256-830-4811 x114
Cell : 256-665-2832

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs