I have to say that this result really doesn't surprise me. AssociationProxy is a bit of magic that was blessed upon us by the core team. However, knowing how any ORM works is key to knowing why these super-helpful callbacks are not infalliable. I think the behaviour is completely expected. How unexpected would *this* be!
>> u = User.find(1) >> u.quote = "Boo Urns" >> m = User.find(1) >> m.first_name = "Hampton" >> m.save And somehow, the User would end up having the quote of "Boo Urns" and the first name "Hampton". Each representation of data from the DB is unique and seperate. They aren't the DB row, but just the object represenation until you save back to the ACID database. That's why your responses made sense to me. If I'm calling another assocation on something, then I expect it to be a seperate object. It would break my expectations if I asked for User.find(1) twice and got the *same* object. I mean, who gets the right data? If I'm not certain of who is king, then who do I replace? >> u = User.find(1) >> u.quote = "Boo Urns" # someone updates the quote on the db from another thread to be "Hello" >> u.save Personally, I'd expect that the quote would then become "Boo Urns"... but if we are actually connecting IDs in the database to single Object instances, then in theory, we would assume some sort of direct correlation between the object-representation and the database that is *direct*. Just my rants after a bottle of wine. There are limits to ORMs that allow the complexity to be addressed. -hampton. On Feb 7, 1:39 pm, "Peter" <[EMAIL PROTECTED]> wrote: > Here's the code from the test rails app I created to verify this > problem: > > Migration: > create_table :products do |t| > t.column :name, :string > end > create_table :categories do |t| > t.column :name, :string > end > create_table :categories_products, :id => false do |t| > t.column :category_id, :integer > t.column :product_id, :integer > end > > Models: > class Product < ActiveRecord::Base > has_and_belongs_to_many :categories > end > class Category < ActiveRecord::Base > has_and_belongs_to_many :products > end > > Controller: > render :text => Category.new(:name => 'test').products.build(:name => > 'test').categories(true).size > > 0 is always rendered by the controller. I also tried saving the new > category first, but that made no difference. > > -peter > > On Feb 7, 10:22 am, Josh Susser <[EMAIL PROTECTED]> wrote: > > > Can you post your schema/migrations for the tables, and the relevant > > assertions from the model classes? > > > On Feb 7, 2007, at 10:10 AM, Peter wrote: > > > > On Feb 6, 6:21 pm, "Mislav Marohnić" <[EMAIL PROTECTED]> > > > wrote: > > >> On 2/6/07, Peter <[EMAIL PROTECTED]> wrote: > > >>> Why does product.categories return an empty array instead of the > > >>> associated category? > > > >> Does "product.categories(true)" return the same for you? > > > > Yes, passing in true for force_reload still returns an empty array. > > > > I've tried patching HasAndBelongsToManyAssociation.build with > > > something like this: > > > record.send(@reflection.active_record.name.tableize) << @owner > > > > But this results in an endless loop during save. > > > > -peter > > > -- > > Josh Susserhttp://blog.hasmanythrough.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
