.Build, .create और .create के बीच अंतर! और उनका उपयोग कब किया जाना चाहिए?

Question

इसलिए मैं लोगों को .build, .create और .create का उपयोग करते हुए देख रहा हूं! उनके नियंत्रकों के भीतर अधिक से अधिक हाल ही में। बस .new का उपयोग करने से क्या अंतर है और परम वस्तु और फिर पास .save पास करना चाहिए? क्या पेशेवरों और विपक्ष हैं? क्या इन अन्य तरीकों का उपयोग करने से लाभ मिलता है?

Answer 1

कुछ अंतर हैं, लेकिन वे बड़े नहीं हैं:

1. .create.newइसके बाद के बराबर है .save। यह सिर्फ अधिक रसीला है।
2. .create!.newइसके बाद के बराबर है .save!(यदि बचत विफल हो जाती है तो एक त्रुटि होती है)। यह भी सिर्फ एक छोटा सा छोटा है
3. मुझे लगता .buildहै कि ज्यादातर के लिए एक उपनाम है .new। यह एक तरह से रेल्स 3 और दूसरे तरीके में रेल्स <3.x पर काम करता है

हालांकि, सबसे महत्वपूर्ण हिस्सा यह है कि इन विधियों has_manyको दो मॉडल से स्वचालित रूप से लिंक करने के लिए एक एसोसिएशन ( आदि) के माध्यम से बुलाया जा सकता है ।

Comments

मैंने इसे सबसे सही उत्तर के रूप में चुना है क्योंकि उल्लेखित मॉडल को उनके साथ जोड़ने में सक्षम होने के कारण - यह एक दिलचस्प और महत्वपूर्ण अंतर है जो मैं .new और .save का उपयोग करने के बारे में सोचता हूं। जो थोड़ा अतिरिक्त काम लेता है। धन्यवाद।

— टिम नाइट

3 पर मामूली स्पष्टीकरण - निर्माण सिर्फ नए से थोड़ा अधिक करता है - यह एसोसिएशन लिंक भी सेट करता है।

— दो बिट गैंगस्टर

बिल्ड न्यू से अलग है। लेकिन अंतर यह नहीं है कि यह एसोसिएशन लिंक को सेट करता है (नया ऐसा नए उदाहरण के लिए भी करता है)। अंतर यह है कि बिल्ड नए उदाहरण के साथ कॉलर को पॉप्युलेट करता है, लेकिन न्यू नहीं करता है। इसलिए उदाहरण के लिए: Wall.posts.new आपको अपनी वॉल से जुड़ी एक नई पोस्ट देता है, लेकिन इस कॉल के बाद भी Wall.posts खाली है। Wall.posts.build आपको आपकी वॉल से जुड़ी एक नई पोस्ट देता है, और अब आपके वॉलपोस्ट में एक पोस्ट है।

— अमीन एरियाना

क्या यह सिर्फ एक उपनाम नहीं है, जिसमें कोई विशेष कार्यक्षमता नहीं है?

— गेब्रियल सेरुल्ली

रेल 4 में, मैंने सिर्फ कंसोल में चेक किया। wall.posts.new और wall.posts.build दोनों दीवार ऑब्जेक्ट को बिल्कुल उसी तरह से पॉप्युलेट कर रहे हैं। Wall.posts.new, wall.post के बाद का अर्थ खाली नहीं है जैसा कि अमीन की टिप्पणी में दावा किया गया है।

— बॉट

Answer 2

हालांकि यह सही है कि createकॉल newऔर फिर saveउनके वापसी मूल्यों में दो विकल्पों के बीच एक बड़ा अंतर है।

Savetrueया तो रिटर्न या falseइस बात पर निर्भर करता है कि ऑब्जेक्ट डेटाबेस में सफलतापूर्वक सहेजा गया था या नहीं। यह तो ऊपर दिए गए प्रश्न में पहले उदाहरण के अनुसार प्रवाह नियंत्रण के लिए इस्तेमाल किया जा सकता है।

Createइस मॉडल की परवाह किए बिना कि वस्तु बचाई गई थी या नहीं। इसमें ऊपर दिए गए कोड के निहितार्थ हैं कि ifकथन की शीर्ष शाखा को हमेशा निष्पादित किया जाएगा, भले ही ऑब्जेक्ट सत्यापन विफल हो और सहेजा नहीं गया हो।

यदि आप createब्रांचिंग लॉजिक के साथ उपयोग करते हैं तो आपको साइलेंट फेलियर का खतरा है जो कि अगर आप new+ का उपयोग करते हैं तो ऐसा नहीं है save।

create! यदि रिकॉर्ड अमान्य है, तो यह उसी समस्या से ग्रस्त नहीं होता, जैसा कि ऊपर उठता है और अपवाद होता है।

createजहां वैकल्पिक नियंत्रकों में उपयोगी हो सकता respond_withएपीआई (JSON / XML) प्रतिक्रिया के लिए प्रयोग किया जाता है। इस स्थिति में ऑब्जेक्ट पर त्रुटियों के अस्तित्व की स्थिति के साथ प्रतिक्रिया में त्रुटियों को वापस करने का कारण होगा unprocessable_entity, जो कि वास्तव में आप एक एपीआई से चाहते हैं।

मैं हमेशा html के लिए new+ saveविकल्प का उपयोग करता हूं , खासकर यदि आप प्रवाह नियंत्रण के लिए वापसी मूल्य पर भरोसा कर रहे हैं।

Answer 3

#create नए और सहेजने का छोटा संस्करण है। #सृजन करना! यदि अपवाद सकारात्मक नहीं था तो अपवाद फेंक रहा है।

Answer 4

मैं उपरोक्त उत्तर दूंगा। इसके अलावा create, कोई falseएक तर्क के रूप में पारित नहीं कर सकता है जिसे आप कर सकते हैं save। falseएक तर्क के रूप में पारित करना सभी रेल मान्यताओं को छोड़ देगा