PostgreSQL Antipatterns: ट्रिगरलाई बाइपास गरेर डाटा परिवर्तन गर्नुहोस्

ढिलो वा चाँडो, धेरैले तालिका रेकर्डमा ठूलो मात्रामा केहि ठीक गर्न आवश्यकताको सामना गरिरहेका छन्। मसँग पहिले नै छ मलाई यो कसरी राम्रो गर्ने भन्नुहोस्, र कसरी - यो नगर्नु राम्रो छ। आज म मास अपडेटको दोस्रो पक्षको बारेमा कुरा गर्नेछु - ट्रिगरहरूको बारेमा.

उदाहरण को लागी, एक टेबल मा जसमा तपाइँ केहि ठीक गर्न आवश्यक छ, एक दुष्ट ट्रिगर ह्याङ्ग छ ON UPDATE, सबै परिवर्तनहरू केही एग्रीगेटहरूमा स्थानान्तरण गर्दै। र तपाईंले सबै कुरा अद्यावधिक गर्न आवश्यक छ (उदाहरणका लागि नयाँ फिल्ड प्रारम्भ गर्नुहोस्) यति होशियारीका साथ कि यी समुच्चयहरू प्रभावित हुँदैनन्।

ट्रिगरहरू असक्षम गरौं!

BEGIN;
  ALTER TABLE ... DISABLE TRIGGER ...;
  UPDATE ...; -- тут долго-долго
  ALTER TABLE ... ENABLE TRIGGER ...;
COMMIT;

वास्तवमा, यो सबै हो - सबै कुरा झुन्डिएको छ.

किनभने ALTER TABLE लगाउँछ पहुँच विशेष- एक ताला जसको मुनि कोही समानान्तरमा चलिरहेको छैन, एक साधारण पनि SELECT, टेबलबाट केहि पढ्न सक्षम हुनेछैन। त्यो हो, यो लेनदेन समाप्त नभएसम्म, "केवल पढ्न" चाहने सबैले पर्खनेछन्। र हामी त्यो सम्झन्छौं UPDATE हामीसँग लामो...

चाँडै यसलाई बन्द गरौं, त्यसपछि चाँडै यसलाई खोल्नुहोस्!

BEGIN;
  ALTER TABLE ... DISABLE TRIGGER ...;
COMMIT;

UPDATE ...;

BEGIN;
  ALTER TABLE ... ENABLE TRIGGER ...;
COMMIT;

यहाँ स्थिति पहिले नै राम्रो छ, प्रतीक्षा समय धेरै कम छ। तर केवल दुई समस्याले सबै सुन्दरतालाई बिगार्छ:

• ALTER TABLE आफैं टेबलमा अन्य सबै अपरेशनहरूको लागि पर्खन्छ, लामोहरू सहित SELECT
• ट्रिगर बन्द हुँदा कुनै पनि परिवर्तन "द्वारा उडान" तालिकामा, हाम्रो पनि होइन। र यो समग्रमा पुग्ने छैन, यद्यपि यो हुनुपर्छ। समस्या!

सत्र चरहरू प्रबन्ध गर्दै

त्यसोभए, अघिल्लो संस्करणमा, हामीले एउटा आधारभूत बिन्दुमा ठोक्क्यौं - हामीले कुनै न कुनै रूपमा तालिकामा "हाम्रो" परिवर्तनहरू "हाम्रो होइन" बाट छुट्याउन ट्रिगरलाई सिकाउनु पर्छ। "हाम्रो" लाई जस्तै छाडिन्छ, तर "हाम्रो होइन" मा ती ट्रिगर हुन्छन्। यसका लागि तपाईले प्रयोग गर्न सक्नुहुन्छ सत्र चरहरू.

सत्र_प्रतिकृति_भूमिका

हामी पढ्छौं म्यानुअल:

ट्रिगर संयन्त्र पनि कन्फिगरेसन चर द्वारा प्रभावित छ सत्र_प्रतिकृति_भूमिका। अतिरिक्त निर्देशन (पूर्वनिर्धारित) बिना सक्षम गरिएको, जब प्रतिकृति भूमिका "मूल" (पूर्वनिर्धारित) वा "स्थानीय" हुन्छ तब ट्रिगरहरू सक्रिय हुनेछन्। ट्रिगरहरू निर्दिष्ट गरेर सक्षम गरियो ENABLE REPLICA, यदि मात्र काम गर्नेछ वर्तमान सत्र मोड - "प्रतिकृति", र निर्दिष्ट गरेर सक्रिय ट्रिगरहरू ENABLE ALWAYS, हालको प्रतिकृति मोडलाई ध्यान नदिई काम गर्नेछ।

म विशेष गरी जोड दिनेछु कि सेटिङ एकैचोटि सबैमा लागू हुँदैन, जस्तै ALTER TABLE, तर हाम्रो छुट्टै विशेष जडानमा मात्र। कुलमा, कुनै पनि अनुप्रयोगले काम ट्रिगर गर्दैन:

SET session_replication_role = replica; -- выключили триггеры
UPDATE ...;
SET session_replication_role = DEFAULT; -- вернули в исходное состояние

ट्रिगर भित्रको अवस्था

तर माथिको विकल्पले एकैचोटि सबै ट्रिगरहरूको लागि काम गर्दछ (वा तपाइँलाई "वैकल्पिक" ट्रिगरहरू पहिले नै चाहिन्छ जुन तपाइँ असक्षम गर्न चाहनुहुन्न)। र यदि हामीलाई आवश्यक छ एक विशिष्ट ट्रिगर "बन्द गर्नुहोस्"?

यसले हामीलाई मद्दत गर्नेछ "प्रयोगकर्ता" सत्र चर:

एक्सटेन्सन प्यारामिटर नामहरू निम्न रूपमा लेखिएका छन्: विस्तारको नाम पछि डट र त्यसपछि प्यारामिटर नाम आफैं, SQL मा पूरा वस्तु नामहरू जस्तै। उदाहरण को लागी: plpgsql.variable_conflict।
किनभने प्रणाली बाहिरका विकल्पहरू उपयुक्त विस्तार मोड्युल लोड नगर्ने प्रक्रियाहरूमा सेट गर्न सकिन्छ, PostgreSQL ले स्वीकार गर्दछ। दुई कम्पोनेन्ट भएका कुनै पनि नामहरूको लागि मानहरू.

पहिले, हामी ट्रिगरलाई अन्तिम रूप दिन्छौं, यो जस्तै:

BEGIN
    -- процессу конвертации можно делать все
    IF current_setting('mycfg.my_table_convert_process') = 'TRUE' THEN
        IF TG_OP IN ('INSERT', 'UPDATE') THEN
            RETURN NEW;
        ELSE
            RETURN OLD;
        END IF;
    END IF;
...

वैसे, यो "लाभको लागि", अवरुद्ध बिना, मार्फत गर्न सकिन्छ CREATE OR REPLACE ट्रिगर प्रकार्यको लागि। र त्यसपछि विशेष जडानमा हामी "हाम्रो" चरलाई कक गर्छौं:

SET mycfg.my_table_convert_process = 'TRUE';
UPDATE ...;
SET mycfg.my_table_convert_process = ''; -- вернули в исходное состояние

के तपाईलाई अन्य तरिकाहरू थाहा छ? कमेन्टमा सेयर गर्नुहोस्।

स्रोत: www.habr.com