(la diferencia es enorme, el primero me devuelve sólo los usuarios cuya
dirección está activa y el segundo todos los usuarios con campos en null si
la dirección no está activa).
Un tiro en la oscuridad, y no se que onda con la performance, pero que
pasa si ponés una condición por address_id no nulo en el find?
Lo que pasa es que las condiciones del where te recortan todo, son el último
filtro antes de llegar a rails. Entonces, si la condición nunca es cierta no
viene nada. Pero si es siempre verdadera vas a matar a rails, porque va a
tener que procesar un resultset enorme.
Por el contrario las condiciones del left outer join pueden no ser válidas nunca y entonces te vienen los campos correspondientes en NULL, y los de la tabla principal según las condiciones.
El caso es sólo una muestra, en realidad las condiciones varían. Creo que la
pregunta es otra, ¿se pueden generar asociaciones con condiciones variables?
Algo como:
has_many :active_addresses, :class_name => :address, :conditions =>
['addresses.is_active = ?',1]
Pero permitiendo que en lugar del '1' haya una variable. Con algo así podría
hacer un ':include => :active_addresses' y listo (como sugiere el manual de AR
en Eager Loading). Pensé en una variable de clase:
has_many :active_addresses, :class_name => :address, :conditions =>
['addresses.is_active = ?',@address_status]
pero está el tema del multihilo ... Si dos hilos quieren diferentes tipos de
búsqueda paramétrica y ese valor está en la clase podría haber problemas.
Igual no sé si se puede. Otra sería agregar una asociación en el momento de
usarla, ahí tendría control total sobre las condiciones.
Eduardo.
_______________________________________________
Ruby mailing list
[email protected]
http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
