2012-06-27 9 views
25

मैं निम्नलिखित कोड है:रेल "find_all_by" बनाम ".where"

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

मैं करने के लिए इसे बदलने के बारे में सोच रहा था:

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

वहाँ इस के लिए किसी भी लाभ होगा? ऐसा लगता है कि .where आजकल find_all_by से अधिक आम है।

+0

मैं रेल से किसी एप्लिकेशन को अपग्रेड करने की प्रक्रिया में हूँ 4.0.3 4.1.0 करने के लिए और मेरे कोड है कि 'इस्तेमाल किया find_all_by' अब काम नहीं करता है ('NoMethodError')। मुझे रिलीज नोट्स में कुछ भी दिखाई नहीं देता है जो इसे प्रभावित करेगा। मुझे 'कहां' पर स्विच करना होगा। अगर मैंने शुरुआत से 'कहां' इस्तेमाल किया था, तो मेरा कोड ऐसी त्रुटियों से कम प्रवण होता। वहां एक टिप्पणी है [http://stackoverflow.com/questions/11232971/rails-find-all-by-vs-where#comment14759921_11233522) यह उल्लेख करते हुए कि 'find_all_by_ *' रेल 4 में बहिष्कृत किया जाएगा। फिर भी, यह आया मुझे आश्चर्य के रूप में। इस विधि को हटाने का दस्तावेज कहां है? – Dennis

+0

मुझे पता चला कि यह कहां दस्तावेज है। 4.1 रिलीज नोट्स में: "सक्रिय निर्भरता-बहिष्कृत_फिंडर्स को एक निर्भरता के रूप में हटाया गया है। कृपया अधिक जानकारी के लिए मणि रीडमे देखें।" – Dennis

+0

मैं इस प्रकार की स्थिति में 'मानचित्र' के बजाय 'प्लक' का उपयोग करने का भी सुझाव दूंगा। 'InfoItem.where (work_order: self.work_order) .pluck (: परिपक्वता)' – jurassic

उत्तर

25

मेरी राय यह है कि .where का उपयोग करना एक बेहतर तरीका है।

जब आप विशेषता आधारित खोजकर्ताओं का उपयोग करते हैं, तो आपको class_eval के माध्यम से एक विधि विधि को परिभाषित करने के लिए एक विधि विधि को परिभाषित करना होगा, जो आपका परिणाम देता है। यह अतिरिक्त प्रसंस्करण है जिसे आपको करने की आवश्यकता नहीं हो सकती है।

इसके अलावा, एक साथ स्ट्रिंग: find_by_this_and_this_and_this_and_this ... बदसूरत हो सकता है।

See how rails accomplishes attribute based finders here

विधि मॉड्यूल DynamicMatchers 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

उत्कृष्ट स्पष्टीकरण – holaSenor

+0

इसमें समय और विचार डालने के लिए धन्यवाद, मैं आपके उत्तर की सराहना करता हूं। मैं एक "मेरा जवाब" के रूप में चिह्नित करने से पहले मैं अन्य सुझावों के लिए कुछ और समय देने की अनुमति दूंगा। धन्यवाद महोदय। – ardavis

+1

आपका स्वागत है। यह केवल मेरी राय है और शायद सबसे अच्छा स्पष्टीकरण नहीं हो सकता है। महान सवाल! – Kyle

2

मुझे लगता है कि मुख्य लाभ डायनामिक चयनकर्ता के क्षेत्र तक सीमित है, जहां अतिरिक्त मानदंड जोड़ने में सक्षम है। यदि आपके पास केवल एक शर्त है जिसे आप खोज रहे हैं तो मुझे लगता है कि यह एक धो है, लेकिन जब आप 3 या 4 जोड़ना शुरू करते हैं, तो गतिशील खोजकर्ता बदसूरत हो सकते हैं। हैश को देखने के लिए अच्छा लगा है, और यदि आवश्यक हो तो आप पैरामीटर के रूप में स्थितियों के हैंश पास कर सकते हैं। गतिशील खोजक शांत हैं, लेकिन मुझे लगता है कि क्लीनर तरीके से स्केल कहां और अधिक पठनीय है।

+0

लेकिन मैं सफलतापूर्वक कुछ ऐसा कर सकता हूं: 'InfoItem.find_all_by_work_order_and_description (self.work_order, "bla bla bla") ' – ardavis

+0

मेरा मतलब यह नहीं है कि आप गतिशील खोजक को और अधिक नहीं जोड़ सकते हैं, लेकिन एक हैश को क्लीनर कहां पैरामीटर के रूप में पास कर सकते हैं। आईएमओ – holaSenor

+2

AFAIK। यह करने का 'रेल 3 रास्ता' है, इसका उल्लेख नहीं करना यह बहुत साफ और अधिक लचीला है। –

संबंधित मुद्दे