On 10/31/07, Diego Algorta Casamayou <[EMAIL PROTECTED]> wrote: > Esta solución es buena. Incluso evita el join entre tablas lo cual la > hace ganar el premio de ser la más ágil y rápida diría yo. > > Pero hay dos problemas con este approach: > > * los counter_cache sólo se mantienen actualizados si las operaciones > de alta y baja son realizados a través del association proxy. > Entonces, si hago AcademicProgram.create(...) el counter_cache en > locations NO se actualiza. Sólo se actualiza si hago: > Location#academic_programs.create(...). A veces, uno utiliza algún > plugin para las pantallas de administración (roar en mi caso) y estos > no tienen en cuenta estas cositas... Sí, podría ver de actualizar > roar, pero por ahora no.
Diego, no usé mucho los counter_cache, pero la vez que los usé me anduvieron perfectamente. Y ni tuve en cuenta lo que decís de agregar a la colección desde el association proxy. Es más, acabo de chequear el código de la aplicación que te digo y los contadores están andando perfecto usando el #create con el hash como viene del formulario (es decir, asignando por location_id). > * Sucede que AcademicProgram tiene otras 3 relaciones del tipo > belongs_to además de location. Qué pasa si quiero poner un > counter_cache en más de una de estas relaciones? Ya no tengo forma de > mantenerlas a todas "the rails way" porque sólo puedo optar por hacer > el create o build desde una de ellas con lo cual los counter_cache de > las otras quedan sin actualizar. Agradezco me desaznen si estoy > equivocado. Bueno, si lo que te decía antes es así, entonces no deberías tener problema en tener muchos counter_cache... Contanos después a ver cómo te fue! _______________________________________________ Ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
