Hi,
I came across a certain use case that could need some fine tuning. Let's
say I have a song Model. This song is available in many formats. So, the
song has_many formats (mp3, flac, ...). The song also has the original
where the other might have been generated from. So, the song has_one
original. This is my current state of affairs:
class Song < ActiveRecord::Base
has_many :formats
has_one :original, class_name: "Format", conditions: { tag: "original" }
end
So far, so good. Problem is, now I have my original made available in two
different places, and if I update one, it is not reproduced on the other,
until I synchronize everything from the database (not to the database).
s = Song.first
s.formats.select{|f| f.tag == "original" } # original original
s.original #original original
s.original = Format.create(.... tag: "original") # changed original
s.formats.select{|f| f.tag == "original" } # original original (!!)
s.reload
s.formats.select{|f| f.tag == "original" } # changed original
And this sucks, specially when I start playing around with validations, I
end up tucking more than I would like to.
So the question is: how well could one devise such an association which is
contained somewhere else? Something like:
class Song < ActiveRecord::Base
has_many :formats
has_one :original, class_name: "Format", conditions: { tag: "original" },*on:
:formats
*
end
And from then on this "has one" would be a proxy to an instance contained
in an has_many collection.
So, what would speak against such a feature? I'm all hears
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
