On 10/31/07, Damian Janowski <[EMAIL PROTECTED]> wrote: > 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).
Mea culpa. ¿Podés creer que antes de responder tu mail anterior, hice la prueba y no me funcionó? Y ahora descubrí... supongo que rails no se da cuenta de la existencia del counter_cache si no salvo los cambios en el modelo al modificar el belongs_to... :P Así que ahora volví a probar y sí, el counter_cache en locations se actualiza al crear y al borrar academic_programs, pero... siempre hay un pero... si alcualizo un academic_program cambiando el location_id, el tipo debería decrementar el counter en el location viejo e incrementarlo en el nuevo. Pues por lo menos usando roar no lo hace. Comprobé que si lo hago desde la consola funciona bien, pero no desde el formulario de edición que me arma roar. Así que lo mejor sería buscar el bug en roar y corregirlo... pero ahora no tengo ganas. :-P Voy a ver si lo hago después. > > > * 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... Esto no lo probé, pero tenés razón. > > Contanos después a ver cómo te fue! Gracias Damián! -- Diego Algorta Casamayou http://www.oboxodo.com - http://diego.algorta.net _______________________________________________ Ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
