I have an application that I started developing under 2.1 and have
progressed through 2.2 and am no attempting to run using 2.3.4.
The application is heavily reliant on ActiveRecord and the ability to
reference objects and attributes using dot notation.
eg:
if I have defined for class ARec
named_scope :for_period, lambda {|f,t| {:conditions => [‘from_date
between ? and ?’, f,t]}}
I typically call:
from_date = ARec.for_period( c.d.e.from, f.g.h.i.to )
or similar within my code.
The problem is that under 2.2.2, c.d.e.from and f.g.h.i.to both loaded
the values from the database as needed, whereas under 2.3.4, when I
run the same code block, the from and to calls both get into
AssociationProxy.load_target (association_proxy.rb : 237) and Rails
determines that the instances have already been loaded, even though
their attribute lists are nil.
The only solution I have found so far is to add a parameter of true to
each object to force the loading. But I don’t really want to do that
to the over 10,000 places in my code where I may need to do this.
What this really seems to indicate is that lazy loading of objects is
broken in Rails 2.3.4 if AR is marking records as loaded when it
hasn’t loaded the attributes.
What can I do (short of going back to Rails 2.2.x) to get Lazy Loading
working application wide for a system with over 400 separate models
and over 20,000 lines of code in my models?
I have an application that I started developing under 2.1 and have
progressed through 2.2 and am no attempting to run using 2.3.4.
The application is heavily reliant on ActiveRecord and the ability to
reference objects and attributes using dot notation.
I think that applies to most applications and is something that should
just work. Have you tried boiling down your problem to an example
small enough to post here ?
What can I do (short of going back to Rails 2.2.x) to get Lazy Loading
working application wide for a system with over 400 separate models
and over 20,000 lines of code in my models?
This is a side issue, but…refactor your codebase! It’s a rare
application indeed that needs 400 models, so I suspect you may have some
stuff that should come out…