Rails: parches y plugins
Iba a contar una historia sobre mi escapada a Las Vegas y mi boda por sorpresa con una actriz de Hollywood (no voy a decir de quien se trata, pero diré que Brad Pitt es un tipo con suerte) pero como nadie se lo iba a creer (no os creáis todo lo que sale en Internet) voy a contar que me ha mantenido ocupado.
Los usuarios son idiotas (esto es como mi versión de la máxima de House “Los pacientes siempre mienten”) y si les dejas romperán tu aplicación. En la aplicación que estoy desarrollando hay algunas jerarquías y algunas relaciones en las que no me interesa permitir que los usuarios eliminen a los padres antes de haber eliminado a los hijos, de forma que no queden ramas colgando o asociaciones a registros inexistentes.
Estaba repitiendo por un muchos modelos unos callbacks con nombres como dont_destroy_with_children. He supuesto que yo era tonto (bueno, eso no tengo que suponerlo, lo sé) y que Rails debía tener una forma de indicar esa condición de forma sencilla. Sin embargo me equivocaba (en lo de Rails, no en lo de ser tonto): en los métodos has_one y has_many hay una opción :dependent pero que sólo ayuda en el caso de que quieras eliminar los registros asociados, no en el caso de que quieras protegerlos.
Buscando me encontré un parche para Ruby on Rails que demostraba que no era el único que tenía ese problema. Lo único malo es que el mismísimo David Heinemeier Hansson no entiende para que podría servir una nueva opción, así que no aplica el parche al código principal de Rails (a pesar de no romper nada en el código ya existente). Así que viendo que no iban a “mezclar” el parche en un futuro cercano y que no me apetece parchear (más) mis instalaciones de Rails me he decidido y he implementado un plugin para Rails que realiza lo mismo que el parche: plugin :dependent => :protect para Rails.
Verdaderamente la potencia de Ruby y sus posibilidades de ampliación se demuestran en lo corto que es el plugin (menos de 20 líneas de código, aunque tiene como cerca de 100 líneas para las pruebas) y que se pueda parchear el código de Rails de una forma tan sencilla.
Pero viendo el comportamiento de David en el comentario del parche anterior (y teniendo un parche supersencillo en espera desde hace 4 meses) me demuestra que Rails no parece un típico proyecto open source donde los parches son bien recibidos. También puede ser que les falte gente para revisar todos los parches que tienen (tienen un montón por aplicar) y parches como el mío (sin pruebas y sin ser críticos) sean puestos al final de la cola (el mío, a pesar de no ser crítico, evita un problema bastante incomodo para los usuarios de Windows). Es una lástima que no vea como convertir ese parche en otro plugin.
Además probando mi plugin he encontrado otro error en el script para instalar plugins que impide que se utilice el método svn export para instalarlos. Es sólo una línea de código, pero como el sitio para desarrolladores de Ruby on Rails está (otra vez) caído no puedo enviar el parche (sí, los enlaces anteriores al sitio no funcionan ahora mismo, lo sé). Por si acaso el parche está aquí aquí uno mejor.
También tiene otro “fallo” el script para instalar plugins: cuando utiliza HTTP para descargar los plugins si la URL termina en “trunk” (la de muchos repositorios de Subversion terminarán así) el script almacenará el plugin en vendor/plugin/trunk que a parte de ser poco descriptivo puede provocar problemas si se instalan dos plugins cuya URL termine en “trunk“. Por ahora no he visto forma fácil de arreglar esto, abriré un informe de error (si el sitio vuele a funcionar) y miraré si se puede arreglar de alguna forma, pero sabiendo el caso que hacen a las pequeñas cosas…
Y así he vuelto a perder un fin de semana, porque después de me he dado cuenta de que en la mayoría de los casos donde yo utilizaba callbacks las asociaciones eran a través de habtm o acts_as_tree, por lo que a mi el plugin no me sirve en muchos casos, aunque espero que le sea útil a alguien.
Actualización: Yo con las prisas. El parche para script/plugin install era incorrecto porque no me leí las instrucciones bien. He hecho otro parche que creo que permite la mayoría de posibilidades. La cosa queda así: por defecto se bajan los plugins mediante HTTP si la URL comienza por http:// o mediante svn export si empieza por svn://, pero puedes forzar el svn export en una URL http:// utilizando la opción -e o --export que el parche añade. Lo demás sigue igual (o esa es la idea).
1 de Agosto de 2006 a las 18:33
¡Hey! ¡Qué bueno que alguien notó mi parche y lo considera útil!
Jeje… buen trabajo con el plugin. Ahora sí… mi parche llegará a las masas… y conquistaré el mundo!
(Si querés, por tu aporte, te dejo la antártida para tí solito).
Saludos desde Uguguay,
Diego
1 de Agosto de 2006 a las 19:58
Ummm… la Antartida… fresquito… (es Verano aquí… y hace muuucho calor :D)