2012-06-27 18 views
25

Tengo el siguiente código:rieles "find_all_by" vs ".donde"

def maturities 
    InfoItem.find_all_by_work_order(self.work_order).map(&:maturity) 
end 

estaba pensando en cambiarlo a:

def maturities 
    InfoItem.where(work_order: self.work_order).map(&:maturity) 
end 

Habría alguna ventaja para esto? Parece que .where es más común que find_all_by en la actualidad.

+0

estoy en el proceso de actualización de una aplicación de Rails 4.0.3 a 4.1.0 y mi código que utiliza ' find_all_by' ya no funciona ('NoMethodError'). No veo nada en las notas de la versión que lo afecte. Tendré que cambiar a 'donde'. Si hubiera usado 'where' desde el principio, mi código habría sido menos propenso a dichos errores. Hay [un comentario más abajo] (http://stackoverflow.com/questions/11232971/rails-find-all-by-vs-where#comment14759921_11233522) mencionando que 'find_all_by_ *' quedaría obsoleto en Rails 4. Sin embargo, esto vino como una sorpresa para mí. ¿Dónde está documentada la eliminación de este método? – Dennis

+0

Encontré dónde está documentado. En las notas de la versión 4.1: "Se eliminó activerecord-deprecated_finders como una dependencia. Consulte la gema README para obtener más información". – Dennis

+0

También sugeriría usar 'pluck' en lugar de' map' en este tipo de situación. 'InfoItem.where (work_order: self.work_order) .pluck (: madurity)' – jurassic

Respuesta

25

Mi opinión es que usar .where es una mejor opción.

Cuando utiliza buscadores basados ​​en atributos, tendrá que pasar por un túnel a través de una llamada faltante del método y finalmente definir un método de clase, a través del class_eval, que devuelve el resultado. Este es un procesamiento adicional que quizás no necesites hacer.

Además, encadenar juntos: find_by_this_and_this_and_this_and_this ... puede ponerse feo.

See how rails accomplishes attribute based finders here

Método falta de DynamicMatchers módulo en github:

def method_missing(name, *arguments, &block) 
    match = Method.match(self, name) 

    if match && match.valid? 
    match.define 
    send(name, *arguments, &block) 
    else 
    super 
    end 
end 
+2

excelente explicación – holaSenor

+0

Gracias por dedicar tiempo y reflexión a esto, agradezco su respuesta. Voy a dejar más tiempo para otras sugerencias antes de marcar una como "mi respuesta". Gracias Señor. – ardavis

+1

De nada. Esta es solo mi opinión y puede que no sea la mejor explicación. Gran pregunta! – Kyle

2

Creo que la principal ventaja es poder agregar criterios adicionales a donde, find_all_by está limitado al campo del selector dinámico. Si solo tienes una condición por la que estás buscando, creo que es un lavado, pero cuando comienzas a agregar 3 o 4, los buscadores dinámicos pueden ser feos. Los hash son agradables de mirar, y podrías pasar un hash de condiciones como parámetro si es necesario. Los buscadores dinámicos son geniales, pero creo que escalan de una manera más limpia y es más legible.

+0

Pero puedo hacer algo como: 'InfoItem.find_all_by_work_order_and_description (self.work_order," bla bla bla ")' – ardavis

+0

No me refiero a eso no puede agregar más a un buscador dinámico, pero pasar un hash como parámetro a donde está más limpio. IMO – holaSenor

+2

AFAIK. ¿Dónde está el 'Rails 3 way' de hacerlo, sin mencionar que es mucho más limpio y más flexible. –

Cuestiones relacionadas