Rails में SQL का उपयोग करना

सबसे पहले, लेख इस बारे में नहीं है कि मुझे रेल कैसे पसंद है, और दूसरी बात, लेख इस बारे में नहीं है कि मैं उनसे कैसे नफरत करता हूं। उनका इलाज पूरी तरह से अलग तरीके से किया जा सकता है और वे तभी बेहतर बनेंगे जब आप उन्हें बदलेंगे। और वे बदतर हो सकते हैं केवल अगर वे बदलना शुरू करते हैं। खैर, सामान्य तौर पर, मैंने आपको चेतावनी दी थी, लेकिन आपने मुझे समझा।

ActiveRecord की मुख्य अवधारणाओं में से एक यह है कि डेटाबेस काफी उपयोगितावादी है और इसे बदला जा सकता है। ठीक है, आप वहां बैठे हैं, MySQL का उपयोग करके अपने मॉडल लिख रहे हैं, और अचानक आपने कहीं पढ़ा है कि आप इसके बजाय MySQL ले सकते हैं और इसे MongbDB के साथ बदल सकते हैं। खैर, इतना कट्टरपंथी नहीं है, लेकिन, कहते हैं, PostgreSQL पर, आपके पास MySQL को बदलने के कारण हो सकते हैं। या इसके विपरीत, मेरे पास MySQL के खिलाफ कुछ भी नहीं है। यहां ActiveRecord आपके लिए इसे आसान बनाने का दावा करता है, माना जाता है कि इससे पहले, फ़िल्टर और एसोसिएशन के बाद, डेटाबेस प्रश्नों को उत्पन्न करने और एप्लिकेशन लॉजिक की देखभाल के बारे में चिंता न करने के लिए पर्याप्त हैं। इसके बजाए WHERE is_archived = TRUE बजाय आप यह WHERE is_archived = TRUE खुश हैं कि where(is_archived: true) और ActiveRecord आपके लिए सब कुछ करेगा। सभी उदाहरण PostgreSQL के लिए अनुवादित किए जाएंगे, MySQL के लिए नहीं, इसलिए MySQL उपयोगकर्ताओं को अपनी बाइक का आविष्कार करना होगा।

लेकिन कोई फर्क नहीं पड़ता कि कैसे! व्यवहार में, यह पता चला है कि अमूर्त की यह परत पूरी तरह से छिद्रों से भरी हुई है, जैसे गोल्डन मछली की कहानी से एक गर्त। और यह कि कई बुनियादी सुविधाओं का उपयोग नहीं किया जा सकता है, जैसे तारीखों की तुलना करना या सरणियों के साथ काम करना। और आपको मजबूरन स्कोप मिलते हैं where("#{quoted_table_name}.finished_at >= ?", Date.current) या where("#{quoted_table_name}.other_ids <@ ARRAY[?]", ids) । जिसके लिए ActiveRecord पूरी तरह से सचेत और तार्किक उत्तर देता है: इसका उपयोग न करें। सरणियों के बजाय, habtm कनेक्शन का उपयोग करें, और यदि आपको तारीखों की तुलना करने की आवश्यकता है, तो इसके साथ रहें। हां, और भगवान ने आपको इस तरह के दायरे में quoted_table_name याद करने के लिए मना किया है - पहले includes या joins सब कुछ अपनी जगह पर joins । यह हर जगह और हमेशा लिखना आसान होता है, ताकि अपना हाथ नीचे न गिराएं।

ठीक है, निश्चित रूप से, जैसे ही आप यहां ActiveRecord के साथ हस्तक्षेप करने का निर्णय लेते हैं, कोई भी मोड़ नहीं होगा। ऐसा नहीं है कि कोई मौका नहीं होगा, यहां तक ​​कि किसी अन्य डेटाबेस में दर्द रहित संक्रमण के लिए एक भूतिया आशा भी। इस सोर्स कोड को प्रिंट करना और जलाना ज्यादा आसान होगा। और हां, आपके आवेदन में अतिरिक्त डेटाबेस सुविधाओं का उपयोग नहीं करने का कोई अन्य कारण नहीं है। स्वास्थ्य पर प्रयोग करें और दूसरों को मजबूर करें!

और जब यह पता चलता है कि मॉडल फ़ोल्डर में आपके स्कोप इन अतिरिक्त सुविधाओं के आधे से अधिक हैं, तो यह काफी स्पष्ट है कि कोड के एक टुकड़े के साथ लेबल के साथ कोड के एक टुकड़े को एकीकृत करने के लिए ActiveRecord सिर्फ एक सुविधाजनक शेल है। और scopes, where(is_archived: true).joins(:sprint).merge(Sprint.archived) , ठीक काम करेगा और उन्हें संयोजित करना तले हुए अंडे बनाने से ज्यादा मुश्किल नहीं होगा, है ना?

अगले चरण का नामकरण होगा। नहीं, विकेंद्रीकरण, जैसा कि यह था, हमेशा गायब नहीं हुआ, लेकिन इसकी देखभाल रेल और ActiveRecord के शक्तिशाली कंधों के साथ आराम करती है, और आप जानते हैं कि इन दो लोगों को संसाधन आवश्यकताओं में तेज और तपस्व में भिन्नता नहीं थी। मान लीजिए कि counter_cache: true COUNT(*) AS sprints_count ओर पहला कदम है, क्योंकि COUNT(*) AS sprints_count आपको ActiveRecord बनाने की अनुमति नहीं देगा (आप सही select() ?), select() को बदलना नहीं चाहेंगे)। और counter_cache परिपूर्ण से बहुत दूर नहीं है, और कुछ मामलों में कैश्ड से वास्तविक राशि का एक वंशानुक्रम हो सकता है। अलौकिक, बेशक, लेकिन अप्रिय। और यह डेटाबेस में बसने वाला पहला उम्मीदवार है और माणिक मशीन के पहले से लोड किए गए सिर को लोड नहीं करता है। सिर्फ एक दो ट्रिगर्स और आप कर रहे हैं! सबसे पहले, प्लेट ए में एक नया रिकॉर्ड हटाते और जोड़ते समय, आपको प्लेट बी में रिकॉर्ड की संख्या और यह सही है, की गणना करने की आवश्यकता है? ठीक है, जब संपादन, ज़ाहिर है, अगर foreign_key बदल गया है, क्योंकि UPDATE B SET a_id = $1 WHERE id = $2 पुराने A और नए दोनों के लिए UPDATE B SET a_id = $1 WHERE id = $2 तोड़ देगा।

  CREATE OR REPLACE FUNCTION update_#{parent_table}_#{child_table}_counter_on_insert() RETURNS TRIGGER AS $$ BEGIN UPDATE #{parent_table} SET #{counter_column} = COALESCE((SELECT COUNT(id) FROM #{child_table} GROUP BY #{foreign_column} HAVING #{foreign_column} = NEW.#{foreign_column}), 0) WHERE (#{parent_table}.id = NEW.#{foreign_column}); RETURN NULL; END; $$ LANGUAGE plpgsql; 

अगला डेटाबेस पथ दिनांक-समय से संबंधित होगा। और शुरुआत के लिए, आइए डेटाबेस में created_at और updated_at फ़ील्ड्स की सेवा करें, सौभाग्य से, यह बहुत सरल है। पहला सेट चूक:

  change_column_default :table_name, :created_at, -> { 'CURRENT_TIMESTAMP' } change_column_default :table_name, :updated_at, -> { 'CURRENT_TIMESTAMP' } 

और तुरंत इसे हर जगह करने के लिए, आप सभी प्लेटों के लिए एक चक्र का आयोजन कर सकते हैं जहां ये क्षेत्र हैं। schema_migrations और ar_internal_metadata अलावा, निश्चित रूप से:

  (tables - %w(schema_migrations ar_internal_metadata)).each { ... } 

यही है, अब इन तालिकाओं के लिए डिफ़ॉल्ट मूल्य वही होगा जो हमें चाहिए। और अब यह सुनिश्चित करने का समय है कि रेल इन क्षेत्रों को न छूएं। यह सही स्थानों में दो बोल्टों के साथ किया जाता है। और हां, इसके लिए जिम्मेदार ढांचा स्थापित करने का एक विकल्प है:

 Rails.application.config.active_record.record_timestamps = false 

इसलिए, अगला चरण रिकॉर्ड किए जाने के समय अपडेट किए updated_at फील्ड को अपडेट करना है। यह सरल है:

  CREATE OR REPLACE FUNCTION touch_for_#{table_name}_on_update() RETURNS TRIGGER AS $$ BEGIN SELECT CURRENT_TIMESTAMP INTO NEW.updated_at; RETURN NEW; END; $$ LANGUAGE plpgsql; 

अब आपको पूरी तरह से touch: true से छुटकारा पाने की आवश्यकता है touch: true मॉडल में touch: true । यह बात डैश में लक्ष्य के समान है - पूरी तरह से छिद्रपूर्ण भी। और मैं यह भी नहीं बता सकता कि क्यों, क्योंकि आप पहले से ही इन सभी मामलों को जानते हैं। यह बहुत अधिक जटिल नहीं है, आपको केवल अपने आप को ही अद्यतन करने की जरूरत है:

  CREATE OR REPLACE FUNCTION touch_for_#{table_name}_on_update() RETURNS TRIGGER AS $$ BEGIN UPDATE foreign_table_name SET updated_at = CURRENT_TIMESTAMP WHERE id = NEW.foreign_column_name; SELECT CURRENT_TIMESTAMP INTO NEW.updated_at; RETURN NEW; END; $$ LANGUAGE plpgsql; 

बेशक, ऐसे ट्रिगर्स की कॉल की श्रृंखला एक अनावश्यक कार्रवाई करेगी, लेकिन साने तंत्र के पोस्टग्रेज में, ट्रिगर्स को रिकॉर्ड को बदलने के बिना ही लागू किया जाता है। आप SET title = title करने की कोशिश कर सकते हैं, लेकिन यह SET updated_at = CURRENT_TIMESTAMP से बेहतर नहीं है।

वास्तव में एक ही ट्रिगर डालने पर होगा, केवल updated_at अद्यतन करना आवश्यक नहीं है:

  CREATE OR REPLACE FUNCTION touch_for_#{table_name}_on_insert() RETURNS TRIGGER AS $$ BEGIN UPDATE foreign_table_name SET updated_at = CURRENT_TIMESTAMP WHERE id = NEW.foreign_column_name; RETURN NEW; END; $$ LANGUAGE plpgsql; 

बेशक, आप IF TG_OP = 'UPDATE' THEN समान, ट्रिगर के अंदर वर्तमान ईवेंट के लिए एक चेक जोड़कर, इसे एक फ़ंक्शन के साथ लिखने का प्रयास कर सकते हैं, लेकिन किसी त्रुटि की संभावना को कम करने के लिए सभी ट्रिगर्स को यथासंभव सरल बनाना बेहतर है।

आप इस तरह के ट्रिगर्स की पीढ़ी को किसी तरह से स्वचालित करना चाहते हैं, और फिर आपको वर्तमान टेबल और बाकी के बीच सभी विदेशी संबंधों को खोजने की आवश्यकता होगी। आप इस प्रश्न को आसानी से कर सकते हैं:

  SELECT ccu.table_name AS foreign_table_name, kcu.column_name AS column_name FROM information_schema.table_constraints AS tc JOIN information_schema.key_column_usage AS kcu ON tc.constraint_name = kcu.constraint_name JOIN information_schema.constraint_column_usage AS ccu ON ccu.constraint_name = tc.constraint_name WHERE constraint_type = 'FOREIGN KEY' AND tc.table_name = '#{table_name}' ORDER BY ccu.table_name; 

एक और बहुत ही उपयोगी टिप। ट्रिगर को उसी तरह से कॉल किया जा सकता है जो किसी अनुरोध के लिए उपस्थिति या अनुपस्थिति को सत्यापित करने में सक्षम हो, उदाहरण के लिए, यह अनुरोध सभी टच-इंसर्ट ट्रिगर पाएंगे:

  SELECT routine_name AS name FROM information_schema.routines WHERE routine_name LIKE 'touch_for_%_on_insert' AND routine_type ='FUNCTION' AND specific_schema='public'; 

और अंत में, सबसे खराब बचा है। तथ्य यह है कि रेल को कम से कम किसी तरह के स्मार्ट डेटाबेस के लिए डिज़ाइन नहीं किया गया है, और उन्होंने वास्तव में इस तथ्य के बारे में परवाह नहीं की है कि id क्षेत्र के अलावा कम से कम कुछ और चीजें डेटाबेस में बदल सकती हैं, और केवल जब डाला जाता है। इसलिए, अनुरोधों को अद्यतन करने के लिए RETURNING updated_at को जोड़ने के लिए कोई भी तंत्र नहीं है।

मैनिपैच बहुत साफ नहीं निकला, लेकिन सबसे पहले यह लक्ष्य था कि जितना संभव हो कम से कम फ्रेमवर्क के मौजूदा काम को नुकसान पहुंचाया जाए।

 module ActiveRecord module Persistence # https://github.com/rails/rails/blob/v5.2.0/activerecord/lib/active_record/persistence.rb#L729-L741 def _create_record(attribute_names = self.attribute_names) attribute_names &= self.class.column_names attributes_values = attributes_with_values_for_create(attribute_names) an_id, *affected_rows = self.class._insert_record(attributes_values).dup self.id ||= an_id if self.class.primary_key Hash[ApplicationRecord.custom_returning_columns(self.class.quoted_table_name, :create).take(affected_rows.size).zip(affected_rows)].each do |column_name, value| public_send("#{column_name}=", self.class.attribute_types[column_name.to_s].deserialize(value)) if value end @new_record = false yield(self) if block_given? id end private :_create_record # https://github.com/rails/rails/blob/v5.2.0/activerecord/lib/active_record/persistence.rb#L710-L725 def _update_record(attribute_names = self.attribute_names) attribute_names &= self.class.column_names attribute_names = attributes_for_update(attribute_names) if attribute_names.empty? affected_rows = [] @_trigger_update_callback = true else affected_rows = _update_row(attribute_names) @_trigger_update_callback = affected_rows.any? end Hash[ApplicationRecord.custom_returning_columns(self.class.quoted_table_name, :update).take(affected_rows.size).zip(affected_rows)].each do |column_name, value| public_send("#{column_name}=", self.class.attribute_types[column_name.to_s].deserialize(value)) end yield(self) if block_given? affected_rows.none? ? 0 : 1 end private :_update_record end module ConnectionAdapters module PostgreSQL module DatabaseStatements # https://github.com/rails/rails/blob/v5.2.0/activerecord/lib/active_record/connection_adapters/postgresql/database_statements.rb#L93-L96 def exec_update(sql, name = nil, binds = []) execute_and_clear(sql_with_returning(sql), name, binds) { |result| Array.wrap(result.values.first) } end # https://github.com/rails/rails/blob/v5.2.0/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb#L147-L152 def insert(arel, name = nil, pk = nil, _id_value = nil, sequence_name = nil, binds = []) sql, binds = to_sql_and_binds(arel, binds) exec_insert(sql, name, binds, pk, sequence_name).rows.first end alias create insert # https://github.com/rails/rails/blob/v5.2.0/activerecord/lib/active_record/connection_adapters/postgresql/database_statements.rb#L98-L111 def sql_for_insert(sql, pk, id_value, sequence_name, binds) # :nodoc: table_ref = extract_table_ref_from_insert_sql(sql) if pk.nil? # Extract the table from the insert sql. Yuck. pk = primary_key(table_ref) if table_ref end returning_columns = quote_returning_column_names(table_ref, pk, :create) if returning_columns.any? sql = "#{sql} RETURNING #{returning_columns.join(', ')}" end super end # No source in original repo def quote_returning_column_names(table_ref, pk, action) returning_columns = [] returning_columns << pk if suppress_composite_primary_key(pk) returning_columns += ApplicationRecord.custom_returning_columns(table_ref, action) returning_columns.map { |column| quote_column_name(column) } end # No source in original repo def sql_with_returning(sql) table_ref = extract_table_ref_from_update_sql(sql) returning_columns = quote_returning_column_names(table_ref, nil, :update) return sql if returning_columns.blank? "#{sql} RETURNING #{returning_columns.join(', ')}" end # No source in original repo def extract_table_ref_from_update_sql(sql) sql[/update\s("[A-Za-z0-9_."\[\]\s]+"|[A-Za-z0-9_."\[\]]+)\s*set/im] Regexp.last_match(1)&.strip end end end end end 

सबसे महत्वपूर्ण बात यह है कि यहाँ हम यह जानने के लिए ApplicationRecord.custom_returning_columns ओर रुख करते हैं कि आईडी के अलावा कौन से कॉलम हमारे लिए दिलचस्प हैं। और यह विधि कुछ इस तरह दिखती है:

  class << self def custom_returning_columns(table_ref, action) return [] if ['"schema_migrations"', '"ar_internal_metadata"'].include?(table_ref) res = [] res << :created_at if action == :create res << :updated_at res += case table_ref when '"user_applications"' [:api_token] when '"users"' [:session_salt, :password_changed_at] # ... else [] end res end end 

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