AI অ্যাপ বিল্ডারের জন্য PostgreSQL ডেটাবেস অ্যাক্সেস

একটি AI অ্যাপ বিল্ডার বিদ্যমান PostgreSQL ডেটাবেসে তার স্কিমার মালিক না হয়েও সংযোগ করতে পারে, তবে PostgreSQL-এ সেই সীমানা বাস্তবভাবে প্রতিষ্ঠা করলেই তা সম্ভব। «প্রোডাকশন বদলাবে না» বলা কোনো প্রম্পট নিয়ন্ত্রণ নয়। আলাদা রোল, ট্রানজ্যাকশনের ডিফল্ট, স্পষ্ট মাইগ্রেশন পর্যালোচনা ও স্কিমা পরীক্ষা হলো নিয়ন্ত্রণ।

নিরাপদ মডেলটি ডেটাবেসের কাজকে তিনটি পথে ভাগ করে। ডিসকভারি মেটাডেটা পড়ে এবং অনুমোদিত ডেটার নমুনা নেয়। অ্যাপ্লিকেশন কেবল প্রয়োজনীয় টেবিল ও অপারেশন পড়ে ও লেখে। স্কিমা পরিবর্তন একজন মানুষ নির্দিষ্ট SQL অনুমোদন করার পর আলাদা মাইগ্রেশন পরিচয়ে চলে। আমি দলগুলোকে এই পথগুলো এক সুবিধাজনক মালিকের শংসাপত্রে মিলিয়ে দিতে দেখেছি, পরে তারা আবিষ্কার করেছে যে একজন এজেন্ট বিশ্বাসযোগ্য শোনানো কলামের নামকে লাইভ টেবিল নতুন করে নকশা করার অনুমতি ভেবেছে। সুবিধা ছিল এক বিকেলের, পরিষ্কার করতে লেগেছে অনেক বেশি সময়।

ডিসকভারি নকশাগতভাবেই শুধু পড়ার জন্য হওয়া উচিত

একটি ডিসকভারি সংযোগের অনুমোদিত স্কিমা বোঝার মতো অ্যাক্সেস দরকার, তা উন্নত করার মতো নয়। এমন একটি লগইন রোল তৈরি করুন যা ডেটাবেস বা রোল তৈরি করতে পারে না, রো সিকিউরিটি এড়িয়ে যেতে পারে না, এবং বড় কোনো গ্রুপ থেকে অপ্রত্যাশিত অনুমতি উত্তরাধিকারসূত্রে পায় না। PostgreSQL নতুন রোলকে এসব ক্ষমতা ছাড়া তৈরি করে, তবে স্পষ্ট ঘোষণা পর্যালোচনায় উদ্দেশ্যটি বোঝায়।

CREATE ROLE app_discovery
  LOGIN
  NOSUPERUSER
  NOCREATEDB
  NOCREATEROLE
  NOINHERIT
  NOBYPASSRLS
  CONNECTION LIMIT 3
  PASSWORD 'replace-through-secret-manager';

ALTER ROLE app_discovery SET default_transaction_read_only = on;
GRANT CONNECT ON DATABASE customer_portal TO app_discovery;
GRANT USAGE ON SCHEMA app TO app_discovery;
GRANT SELECT ON ALL TABLES IN SCHEMA app TO app_discovery;

default_transaction_read_only ডিফল্ট ধরে রাখা সেশনে সাধারণ লেখার কাজ আটকে দেয়। এটি কাজে লাগে, তবে মূল সুরক্ষা নয়। ক্লায়েন্ট ট্রানজ্যাকশনের সেটিং বদলালেও INSERT, UPDATE, DELETE, TRUNCATE, CREATE ও মালিকানার অভাব রোলটিকে সীমার মধ্যে রাখে। রোলটিকে কোনো অ্যাপ্লিকেশন মালিক গ্রুপের সদস্য করবেন না এবং কোনো স্কিমার মালিকও করবেন না।

বিল্ডার সংযোগের আগে বিদ্যমান অনুমতিগুলো পরীক্ষা করা দরকার। নিচের কোয়েরিটি প্রতিটি টেবিল অনুমতির জন্য একটি করে সারি দেয়, যাতে পর্যালোচক SELECT-এর বাইরে কিছু থাকলে দেখতে পারেন:

SELECT table_schema, table_name, privilege_type
FROM information_schema.role_table_grants
WHERE grantee = 'app_discovery'
ORDER BY table_schema, table_name, privilege_type;

স্বাভাবিক ফল দেখতে হয় app | invoices | SELECT-এর মতো। ফাঁকা ফলের অর্থ হতে পারে ডিসকভারি প্রয়োজনীয় টেবিলটি দেখতে পাচ্ছে না। UPDATE দিয়ে শেষ হওয়া সারির অর্থ রোলটি অতিরিক্ত ক্ষমতাবান। has_schema_privilege দিয়ে স্কিমার অনুমতি এবং has_database_privilege দিয়ে ডেটাবেসের অনুমতিও দেখুন, কারণ টেবিল অনুমতি থেকে বোঝা যায় না রোলটি অন্য কোথাও অবজেক্ট তৈরি করতে পারে কি না।

প্রোডাকশন স্ন্যাপশটকে মালিকের শংসাপত্র ভাগাভাগির অজুহাত বানাবেন না। একটি কপিতেও গ্রাহকের ডেটা থাকতে পারে, আর মালিকানা থাকা এজেন্ট সেটিকে এতটাই বদলাতে পারে যে পরে তুলনা অর্থহীন হয়ে যায়। প্রতিটি পরিবেশে ডিসকভারির জন্য আলাদা পরিচয় দিন।

ক্যাটালগ পরীক্ষা অনুমোদিত তালিকার মধ্যেই থাকতে হবে

বিল্ডারের কেবল অনুমোদিত স্কিমা আবিষ্কার করা এবং PostgreSQL যা সত্যিই জানায় তা নথিবদ্ধ করা উচিত। information_schema টেবিল, কলাম, কনস্ট্রেইন্ট ও অনুমতির জন্য বহনযোগ্য ভিউ দেয়। pg_catalog ইনডেক্স, টাইপ, জেনারেট করা এক্সপ্রেশন ও রো সিকিউরিটির মতো PostgreSQL-এর বিস্তারিত তথ্য দেয়। সাধারণ গ্রাহক টেবিল সম্পর্কে কোনো LLM-এর স্মৃতির চেয়ে দুটিই ভালো উৎস।

app ও reporting-এর মতো একটি অনুমোদিত তালিকা দিয়ে শুরু করুন। pg_catalog, information_schema, অস্থায়ী স্কিমা, এক্সটেনশন স্কিমা এবং তালিকাভুক্ত নয় এমন প্রতিটি টেন্যান্ট স্কিমাকে অ্যাপ্লিকেশনের লক্ষ্য হিসেবে প্রত্যাখ্যান করুন। কোয়েরিতে ডেটাবেস, রোল ও SQL স্তরে ফিল্টার থাকা উচিত। শুধু প্রম্পট স্তরের অনুমোদিত তালিকা পরের কোনো চ্যাটে হারিয়ে যেতে পারে।

SELECT
  c.table_schema,
  c.table_name,
  c.ordinal_position,
  c.column_name,
  c.data_type,
  c.is_nullable,
  c.column_default
FROM information_schema.columns AS c
WHERE c.table_schema IN ('app', 'reporting')
ORDER BY c.table_schema, c.table_name, c.ordinal_position;

ফলটি সংগ্রহের সময় ও ডেটাবেস শনাক্তকারীসহ স্কিমা স্ন্যাপশট হিসেবে রাখুন। জেনারেটর কী দেখেছে, তার প্রমাণ হলো এই স্ন্যাপশট। এটি চিরস্থায়ী সত্য নয়। ডিসকভারি ও কোড জেনারেশনের মাঝখানে PostgreSQL বদলে যেতে পারে, তাই ডিপ্লয়মেন্টের আগে নতুন ফিঙ্গারপ্রিন্টের সঙ্গে তুলনা করুন। ব্যবহারযোগ্য একটি ফিঙ্গারপ্রিন্ট ক্রমানুসারে টেবিল, কলাম, টাইপ, নালযোগ্যতা, ডিফল্ট, কনস্ট্রেইন্ট ও ইনডেক্সের বর্ণনা হ্যাশ করতে পারে। ফিঙ্গারপ্রিন্ট ভিন্ন হলে থামুন এবং কোন পরিবর্তন ক্ষতিকর নয় তা অনুমান না করে আবার ডিসকভারি করুন।

সারি নমুনা নেওয়া আলাদা অনুমতির সিদ্ধান্ত। কলামের মেটাডেটায় সাধারণত ব্যক্তিগত ডেটা থাকে না, কিন্তু সারির নমুনায় প্রায়ই থাকে। কোড জেনারেশনের জন্য শূন্য সারি নমুনা বেছে নিন। উদাহরণ দরকার হলে এমন একটি ভিউ প্রকাশ করুন যা গোপন তথ্য ও সরাসরি পরিচয়চিহ্ন মুছে বা মাস্ক করে, তারপর কেবল সেই ভিউতে SELECT দিন। LIMIT 10 সংবেদনশীল কোয়েরিকে নিরাপদ করে না, ফাঁসের পরিমাণ শুধু ছোট করে।

সার্চ পাথও একইভাবে দেখুন। অনুমোদিত স্কিমা ও pg_catalog-এ সেট করুন, তৈরি হওয়া টেবিলের নাম পুরোপুরি উল্লেখ করুন এবং PostgreSQL প্রথমে যে অবজেক্ট খুঁজে পায় তার ওপর ভরসা করবেন না। আক্রমণকারী বা অসতর্ক মাইগ্রেশন লেখার অনুমতিসহ স্কিমায় একই নামের অবজেক্ট তৈরি করতে পারে। app.orders-এর মতো পূর্ণ নাম সেই অস্পষ্টতা দূর করে।

রানটাইম রোলটি প্রকৃত ব্যবহারকারীর কাজের সঙ্গে মিলতে হবে

ডিসকভারি ও রানটাইম আলাদা কাজ। রানটাইম অ্যাপ্লিকেশনকে অর্ডার যোগ করা, খসড়া আপডেট করা বা সতর্কভাবে নকশা করা ফাংশন কল করা লাগতে পারে, কিন্তু তাই বলে আবিষ্কৃত পুরো স্কিমাজুড়ে ব্যাপক লেখার অনুমতি সমর্থন করে না। ব্যবহারকারীর কাজ থেকে অনুমতির ম্যাট্রিক্স তৈরি করুন, তারপর প্রতিটি কাজকে ক্ষুদ্রতম PostgreSQL অনুমতিতে রূপ দিন।

উদাহরণ হিসেবে, ইনভয়েস দেখার ফিচারের app.invoices ও app.invoice_lines-এ SELECT লাগতে পারে, আর নোট ফিচারের app.invoice_notes-এ SELECT ও INSERT দরকার। ইনভয়েসে সম্ভবত DELETE, পাসওয়ার্ড রিসেট রেকর্ডে অ্যাক্সেস বা স্কিমা তৈরির দরকার নেই। সত্যিই কোনো ইনসার্ট ওই সিকোয়েন্সের ওপর নির্ভর করলেই শুধু সিকোয়েন্স ব্যবহারের অনুমতি দিন। PostgreSQL সিকোয়েন্সকে আলাদা অবজেক্ট হিসেবে দেখে, যা মালিকের অ্যাকাউন্ট দিয়ে পরীক্ষা করা জেনারেটরকে অবাক করে।

ভিউ ও ফাংশন আরও সীমিত পৃষ্ঠ দিতে পারে। ভিউ অনুমোদিত কলাম দেখাতে পারে, আর ভেতরের ফিল্ড আড়াল করতে পারে। SECURITY DEFINER ফাংশন এমন একটি নিয়ন্ত্রিত কাজ করতে পারে যা সাধারণ অনুমতিতে প্রকাশ করা যায় না, তবে তার স্থির search_path, কঠোর ইনপুট পরীক্ষা এবং অপ্রয়োজনীয় ক্ষমতাহীন মালিক দরকার। এই ফাংশনকে অনুমতির মডেল এড়িয়ে যাওয়ার শর্টকাট নয়, বিশেষাধিকারপ্রাপ্ত কোড হিসেবে দেখুন।

রো লেভেল সিকিউরিটি ভাগ করা টেবিলের মধ্যে ডেটার সীমানা যোগ করে। এটি টেবিল অনুমতির বিকল্প নয়। PostgreSQL আগে দেখে রোলটি অপারেশনটি করতে পারে কি না, তারপর চালু ও প্রযোজ্য হলে রো সিকিউরিটি নীতি প্রয়োগ করে। নির্দিষ্ট রানটাইম রোল দিয়ে পরীক্ষা করুন, কারণ টেবিলের মালিক এবং BYPASSRLS থাকা রোল নীতি এড়িয়ে যেতে পারে। মাইগ্রেশন মালিকের অধীনে চালানো পরীক্ষা শেষ ব্যবহারকারী কী দেখতে পারে, তার প্রায় কিছুই প্রমাণ করে না।

প্রম্পট, তৈরি করা সোর্স, ব্রাউজার বান্ডল, বিল্ড লগ ও স্ক্রিনশট থেকে গোপন তথ্য দূরে রাখুন। রানটাইম শংসাপত্র হোস্টিং পরিবেশের সিক্রেট স্টোরে রাখুন এবং শুধু সার্ভার প্রক্রিয়ায় দিন। মোবাইল ও ব্রাউজার অ্যাপ PostgreSQL পাসওয়ার্ড গোপন রাখতে পারে না, তাই সরাসরি সংযোগের বদলে সার্ভার API কল করা উচিত। ডিসকভারি, রানটাইম ও মাইগ্রেশন শংসাপত্র আলাদাভাবে ঘোরান। এক পথে ফাঁস হলে অন্য দুটি পথ যেন না খোলে।

মাইগ্রেশনের ক্ষমতার জন্য আলাদা অনুমোদনের পথ দরকার

অ্যাপ বিল্ডার মাইগ্রেশন প্রস্তাব করতে পারে, তবে ডিসকভারি বা রানটাইম সেশন দিয়ে তা চালানো উচিত নয়। মাইগ্রেশনের কাজের জন্য আলাদা রোল দিন, অথবা প্রতিষ্ঠিত ডিপ্লয়মেন্ট সিস্টেমকে একটি অনুমোদিত জবের জন্য সেই রোল গ্রহণ করতে দিন। সাধারণ চ্যাট ও প্রিভিউ সেশনে এর শংসাপত্র অপ্রাপ্য রাখুন।

অনুমোদনে নির্দিষ্ট SQL, লক্ষ্য ডেটাবেসের পরিচয়, এটি তৈরিতে ব্যবহৃত স্কিমা ফিঙ্গারপ্রিন্ট এবং প্রত্যাশিত লক বা রিরাইট আচরণ অন্তর্ভুক্ত থাকতে হবে। «গ্রাহকের স্ট্যাটাস যোগ করুন»-এর মতো স্বাভাবিক ভাষার বাক্য অনুমোদন করলে অনেক কিছু অনির্ধারিত থাকে। চালানো পরিবর্তনটি নালযোগ্য টেক্সট কলাম যোগ করতে পারে, বড় টেবিল নতুন করে গড়তে পারে, enum বানাতে পারে বা বিদ্যমান প্রতিটি সারি আপডেট করতে পারে। এগুলো ভিন্ন ব্যর্থতার ধরনসহ আলাদা অপারেশন।

আমি একটি সংক্ষিপ্ত মাইগ্রেশন প্যাকেট ব্যবহার করি:

1. পরিবর্তনের কারণ এবং যে অ্যাপ্লিকেশন সংস্করণে এটি প্রয়োজন।
2. নির্দিষ্ট ফরওয়ার্ড SQL এবং, যেখানে সৎভাবে দেওয়া যায়, নির্দিষ্ট রিভার্সাল SQL।
3. কমান্ডগুলো যে অবজেক্ট, অনুমতি ও সারিকে প্রভাবিত করতে পারে।
4. প্রিফ্লাইট কোয়েরি, প্রত্যাশিত ফল এবং নতুন স্কিমা ফিঙ্গারপ্রিন্ট।
5. লক টাইমআউট, স্টেটমেন্ট টাইমআউট, ব্যাকআপ বা স্ন্যাপশটের রেফারেন্স এবং রিলিজের মালিক।

রিভার্সাল স্ক্রিপ্ট সবসময় রোলব্যাক নয়। নতুন যোগ করা কলাম বাদ দিলে ক্যাটালগ পরিবর্তন উল্টানো যায়, তবে রিলিজের পর সেই কলামে লেখা ডেটাও নষ্ট হয়। PostgreSQL-এর ট্রানজ্যাকশনাল DDL অনেক ক্যাটালগ অপারেশনে সহায়তা করে, তবু ট্রানজ্যাকশন বাইরের পার্শ্বপ্রতিক্রিয়া বা পরের কমান্ডে মুছে যাওয়া ডেটা ফিরিয়ে আনতে পারে না। DOWN-কে জাদুর শব্দ ভাবার বদলে ধ্বংসাত্মক রিভার্সাল স্পষ্ট করে চিহ্নিত করুন।

lock_timeout সেট করুন, যাতে ব্যস্ত ট্রানজ্যাকশনের পেছনে অপেক্ষা করে নতুন কাজ আটকে দেওয়ার বদলে মাইগ্রেশন ব্যর্থ হয়। পর্যালোচিত অপারেশন অনুযায়ী statement_timeout সেট করুন। পরিবর্তনের সময়সীমার মধ্যে আবার প্রিফ্লাইট কোয়েরি চালান। টেবিলের আকার, সাংঘর্ষিক অবজেক্ট, নাল সংখ্যা বা স্কিমা ফিঙ্গারপ্রিন্ট অনুমোদিত অনুমানের সঙ্গে না মিললে বাতিল করুন। এজেন্টের নতুন করে প্রোডাকশনের বিরুদ্ধে মাইগ্রেশন বানানোর বদলে অমিলের প্রতিবেদন দেওয়া উচিত।

তৈরি করা পরীক্ষা পাশ করেছে বলে মাইগ্রেশন স্বয়ংক্রিয়ভাবে অনুমোদন করবেন না। পরীক্ষা সাধারণত ছোট, পরিচ্ছন্ন স্কিমায় চলে এবং লক কিউ, পুরোনো নাল, অস্বাভাবিক কনস্ট্রেইন্ট, এক্সটেনশন ও ট্র্যাফিক সার্ভ করা অ্যাপ্লিকেশনের সংস্করণগুলো এড়িয়ে যায়। অনুমোদনের সময় একজন মানুষ তৈরি করা উদ্দেশ্যের সঙ্গে লাইভ সিস্টেম মিলিয়ে দেখেন।

কানেকশন পুলিং নিরাপত্তার হিসাব বদলে দেয়

পুল ডেটাবেস সেশন পুনর্ব্যবহার করে, তাই একটি রিকোয়েস্টে তৈরি সেশনের অবস্থা পরের রিকোয়েস্ট পর্যন্ত থেকে যেতে পারে। একটি রিকোয়েস্ট SET search_path চালালে, রোল বদলালে, অস্থায়ী অবজেক্ট তৈরি করলে বা টাইমআউট বন্ধ করলে পরের ব্যবহারকারী তার প্রভাব পেতে পারে। অ্যাপ্লিকেশনকে হয় পরিবর্তনযোগ্য সেশন অবস্থা এড়িয়ে চলতে হবে, নয়তো সংযোগ পুলে ফেরার সময় নির্ভরযোগ্যভাবে রিসেট করতে হবে।

ট্রানজ্যাকশন পুলিং সীমানাকে আরও কঠোর করে। প্রতিটি ট্রানজ্যাকশনের পরে ক্লায়েন্ট ভিন্ন সার্ভার সেশন পেতে পারে, ফলে সেশন-নির্ভর প্রস্তুত স্টেটমেন্ট, অস্থায়ী টেবিল, অ্যাডভাইজরি লক ও সেশন স্তরের সেটিংয়ের ধারণা ভেঙে যায়। বিল্ডাররা প্রায়ই এমন কোড তৈরি করে যা সরাসরি সংযোগে কাজ করে, কিন্তু পুলের পেছনে ব্যর্থ হয়, কারণ এই পার্থক্যটি তাদের মডেলে নেই। পুল সেশন না ট্রানজ্যাকশন মোডে চলবে ঠিক করুন, তারপর জেনারেশন ও পরীক্ষায় সেই মোড অন্তর্ভুক্ত করুন।

ডিপ্লয়মেন্টের আগে সংযোগের বাজেট করুন। ডেটাবেসের অনুমোদিত সংযোগ থেকে প্রশাসন, মাইগ্রেশন, মনিটরিং ও অন্যান্য সার্ভিসের জন্য জায়গা রাখুন, তারপর অবশিষ্ট অংশ অ্যাপ্লিকেশন ইনস্ট্যান্সে ভাগ করুন। দশটি ইনস্ট্যান্স প্রতিটি বিশটি সংযোগ খুললে, ট্র্যাফিক শান্ত থাকলেও PostgreSQL দুইশো সম্ভাব্য সেশন দেখে। ডেটাবেস সংযোগ প্রত্যাখ্যান করা পর্যন্ত সংখ্যা বাড়ানোর চেয়ে কিউ-সহ রক্ষণশীল ছোট পুল সাধারণত নিরাপদ।

সার্ভার-দিকের টাইমআউটকে শেষ সুরক্ষা হিসেবে ব্যবহার করুন: statement_timeout দীর্ঘ স্টেটমেন্ট সীমিত করে, lock_timeout লকের অপেক্ষা সীমিত করে, আর idle_in_transaction_session_timeout কিছু না করেও ট্রানজ্যাকশন খোলা রাখা সেশন সরিয়ে দেয়। প্রতিটি তৈরি করা ক্লায়েন্ট মনে রাখবে ধরে না নিয়ে রোলভেদে মান সেট করুন। প্রকৃত রোল এবং প্রকৃত পুলের মাধ্যমে SHOW চালিয়ে যাচাই করুন।

হেলথ চেক সস্তা হওয়া উচিত। SELECT 1 একটি রাউন্ড ট্রিপ নিশ্চিত করে, কিন্তু অ্যাপ্লিকেশন অনুমোদিত টেবিলে পৌঁছাতে পারে কি না বা তার সার্চ পাথ সঠিক কি না নিশ্চিত করে না। রেডিনেস চেক রানটাইম রোল দিয়ে ছোট, স্থিতিশীল ভিউ কোয়েরি করতে পারে। অ্যাপ্লিকেশন চালুর সঙ্গে মাইগ্রেশন জুড়বেন না। একই সময়ে একাধিক ইনস্ট্যান্স স্কিমা বদলানোর প্রতিযোগিতায় নামলে এই নকশা যে সংযোগ কমাতে চায়, সেটিই তৈরি হয়।

বানানো কলাম কোয়েরি চালুর আগেই ব্যর্থ হওয়া উচিত

LLM বিশ্বাসযোগ্য শোনানো পরিচায়ক বানিয়ে ফেলে। প্রম্পটে গ্রাহকের প্রদর্শন নামের কথা থাকলে, ডেটাবেসে given_name ও family_name থাকলেও তৈরি হওয়া কোড customers.display_name খুঁজতে পারে। ডেটাবেস সেই কোয়েরি প্রত্যাখ্যান করবে, যা ভুল ফিল্ড নীরবে পড়ার চেয়ে ভালো, কিন্তু প্রোডাকশন ত্রুটি স্কিমা যাচাইয়ের ভালো কৌশল নয়।

অনুমোদিত ক্যাটালগ স্ন্যাপশট থেকে টাইপ করা স্কিমা আর্টিফ্যাক্ট তৈরি করুন এবং কোয়েরি তৈরির একমাত্র উৎস হিসেবে সেটি ব্যবহার করুন। সেই আর্টিফ্যাক্টে অনুপস্থিত টেবিল বা কলাম জেনারেশন ত্রুটি ঘটাবে। কাজটি স্পষ্টভাবে মাইগ্রেশন পথে না গেলে মডেলকে মাইগ্রেশন যোগ করে ত্রুটি সারাতে দেবেন না। অনুপস্থিত পরিচায়ক মানে পুরোনো ডিসকভারি, বানান ভুল, ভুল পরিবেশ বা প্রকৃত পণ্যের চাহিদা হতে পারে। প্রতিটির প্রতিক্রিয়া আলাদা।

স্ট্যাটিক পরীক্ষায় SQL পার্স করে স্ন্যাপশটের বিপরীতে প্রতিটি রিলেশন ও কলাম রিজলভ করা উচিত। তারপর লেখার অনুমতি নেই এমন ট্রানজ্যাকশন বা বাতিলযোগ্য ডেটাবেসে স্টেটমেন্ট প্রস্তুত করুন। সফল ব্যবসায়িক ডেটা ছাড়াই PostgreSQL পার্সার অজানা কলাম, অস্পষ্ট রেফারেন্স, অপারেটর টাইপ ত্রুটি ও অনেক ভুল কাস্ট ধরতে পারে। রানটাইম রোল দিয়ে ইন্টিগ্রেশন পরীক্ষা চালান, যাতে অনুমতি ও রো নীতি অংশ নেয়।

ব্যর্থতার প্রতিবেদনে সিদ্ধান্ত নেওয়ার মতো যথেষ্ট তথ্য থাকা দরকার। SQL অবস্থান, রিজলভ না হওয়া পরিচায়ক, কাছের বৈধ পরিচায়ক, স্ন্যাপশট ফিঙ্গারপ্রিন্ট এবং লক্ষ্য ডেটাবেসের পরিচয় অন্তর্ভুক্ত করুন। পরামর্শ কাজে লাগে, কিন্তু স্বয়ংক্রিয় আনুমানিক প্রতিস্থাপন বিপজ্জনক। নাম কাছাকাছি বলে billing_address_id-কে shipping_address_id করলে SQL বৈধ হলেও ব্যবসায়িক অর্থ ভুল হতে পারে।

ডাইনামিক ফিল্টার ও সাজানোর ক্ষেত্রে পাবলিক API নামকে সম্পূর্ণ নামযুক্ত SQL এক্সপ্রেশনের বন্ধ সেটে ম্যাপ করুন। ভ্যালু প্যারামিটারের মাধ্যমে হলেও মডেলের দেওয়া পরিচায়ক কখনো SQL-এ বসাবেন না। প্যারামিটার ভ্যালু সুরক্ষিত করে, টেবিল বা কলামের নাম নয়। ব্যবহারকারী সাজানোর ফিল্ড বেছে নিতে পারলে created-কে app.orders.created_at-এর মতো পরিচিত এক্সপ্রেশনে রূপ দিন। অজানা প্রতিটি টোকেন প্রত্যাখ্যান করুন।

স্কিমা ড্রিফট রিলিজ থামাবে, সৃজনশীল মিলমিশ শুরু করবে না। স্ন্যাপশট আবার তৈরি করুন, পার্থক্য দেখান এবং পরীক্ষা পুনরাবৃত্তি করুন। এই বিলম্ব খুঁতখুঁতে মনে হতে পারে, কিন্তু ডেটাবেস সম্পর্কে যার ধারণা কেবল কথোপকথনের ট্রান্সক্রিপ্টে আছে, এমন কোড ডিপ্লয় করার চেয়ে এর খরচ কম।

ধ্বংসাত্মক SQL-এর জন্য নিষেধ নীতি ও প্রমাণ দরকার

কেউ চালানোর আগেই বিল্ডারের SQL শ্রেণিবদ্ধ করা উচিত। DROP, TRUNCATE, পর্যালোচিত শর্ত ছাড়া ব্যাপক DELETE বা UPDATE, মালিকানা পরিবর্তন, অনুমতি বৃদ্ধি, এক্সটেনশন পরিবর্তন এবং অনুমোদিত স্কিমার বাইরের কমান্ড আটকান। ALTER TABLE-কে স্বয়ংক্রিয়ভাবে নিরাপদ না ধরে পর্যালোচনা প্রয়োজন হিসেবে দেখুন। কলামের টাইপ পরিবর্তন বা নতুন নাল-বিহীন কনস্ট্রেইন্ট ডেটা স্ক্যান বা রিরাইট করতে পারে এবং গুরুত্বপূর্ণ লক ধরে রাখতে পারে।

শুধু টেক্সট মেলানো দুর্বল, কারণ SQL-এ মন্তব্য, উদ্ধৃত পরিচায়ক, ফাংশন ও পার্শ্বপ্রতিক্রিয়া প্রকাশের অনেক পথ আছে। PostgreSQL বোঝে এমন পার্সার দিয়ে স্টেটমেন্ট পার্স করুন, তাদের সিনট্যাক্স ট্রি পরীক্ষা করুন এবং নিষিদ্ধ কাজ অস্বীকার করতে ডেটাবেস রোলের ওপরও নির্ভর করুন। শ্রেণিবিন্যাস পর্যালোচনা উন্নত করে, অনুমতি সীমানা কার্যকর করে। কোনো একটিকে পুরো দায়িত্ব বহন করা উচিত নয়।

মাইগ্রেশনটি সত্যিকারের টেবিল গঠন বা ডেটা বণ্টনের ওপর নির্ভর করলে সাম্প্রতিক, যথাযথভাবে সুরক্ষিত স্ন্যাপশট থেকে পুনরুদ্ধার করা স্টেজিং ডেটাবেস ব্যবহার করুন। সেখানে নির্দিষ্ট মাইগ্রেশন প্যাকেট প্রয়োগ করুন, সময়কাল ও লক সংক্রান্ত পর্যবেক্ষণ নিন, রানটাইম শংসাপত্র দিয়ে অ্যাপ্লিকেশন পরীক্ষা চালান, তারপর পরিবেশটি বাতিল করুন। স্টেজিং ও প্রোডাকশনের মধ্যে নীরবে SQL সম্পাদনা করবেন না। যেকোনো সম্পাদনাই নতুন আর্টিফ্যাক্ট, যার নতুন ফিঙ্গারপ্রিন্ট ও অনুমোদন দরকার।

লগে গোপন তথ্য বা সংবেদনশীল সারি না রেখেও প্রস্তাবকে কার্যকরের সঙ্গে যুক্ত রাখা উচিত। অপরিবর্তনীয় মাইগ্রেশন আর্টিফ্যাক্ট কে অনুমোদন করেছেন, তার ডাইজেস্ট, লক্ষ্য পরিচয়, শুরু ও শেষের অবস্থা এবং PostgreSQL ত্রুটির বিস্তারিত নথিবদ্ধ করুন। তৈরি করা ডিফ ও প্রিফ্লাইট ফল সংরক্ষণ করুন। এজেন্ট চ্যাট দরকারি প্রেক্ষাপট, তবে এটি অডিট রেকর্ড নয়, কারণ ব্যবহারকারী শাখা করতে, আবার চেষ্টা করতে ও নির্দেশনা অন্যভাবে বলতে পারেন।

স্ন্যাপশট ও রোলব্যাক নিয়ন্ত্রণ পুনরুদ্ধারের সময় কমায়, কিন্তু ধ্বংসাত্মক SQL গ্রহণযোগ্য করে না। স্ন্যাপশট পুরো ডেটাবেসকে আগের অবস্থায় ফেরাতে পারে, যখন আসল প্রয়োজন একটি বাদ পড়া কলাম, এবং পুনরুদ্ধারে স্ন্যাপশটের পরের বৈধ লেখাও বাদ যেতে পারে। পুনরুদ্ধার আলাদাভাবে পরীক্ষা করুন এবং কে তা চালাতে পারবেন নথিবদ্ধ করুন।

আমি যখন প্রতিষ্ঠিত ডেটাবেস ছোঁয়া কোনো অ্যাপের জন্য Koder.ai ব্যবহার করি, তখন এক্সপোর্ট করা সোর্স ও প্রস্তাবিত ডেটাবেস সীমানা পর্যালোচনা না করা পর্যন্ত কাজ পরিকল্পনা মোডেই রাখি। স্ন্যাপশট ও রোলব্যাক পুনরুদ্ধারের নিয়ন্ত্রণ, পর্যালোচনা এড়িয়ে যাওয়ার অনুমতি নয়। একই নিয়ম সব বিল্ডারের জন্য প্রযোজ্য: পণ্যের সুবিধা ডেটাবেসের প্রয়োগ করা সুরক্ষার পেছনে থাকতে হবে।

স্কিমা পরিবর্তনকে মিশ্র অ্যাপ্লিকেশন সংস্করণ সহ্য করতে হবে

রিলিজের সময় পুরোনো ও নতুন, দুই অ্যাপ্লিকেশনই চলতে পারলে মাইগ্রেশন নিরাপদ। প্রোডাকশন খুব কমই এক মুহূর্তে এক সংস্করণ থেকে আরেকটিতে যায়। নতুন ইনস্ট্যান্স চালুর সময় রিকোয়েস্ট পুরোনো ইনস্ট্যান্সে যেতে পারে, কিউ করা জবে পুরোনো পেলোড থাকতে পারে, আর রোলব্যাক আজকের স্কিমার বিরুদ্ধে গতকালের কোড ফিরিয়ে দিতে পারে। যে অ্যাপ বিল্ডার শুধু চূড়ান্ত কোডকে চূড়ান্ত স্কিমার সঙ্গে যাচাই করে, সে এই ওভারল্যাপটি এড়িয়ে যায়।

আগে সংযোজনমূলক পরিবর্তন বেছে নিন। নালযোগ্য কলাম, নতুন টেবিল বা পুরোনো পথ না সরিয়ে নতুন ইনডেক্স যোগ করুন। এমন কোড ডিপ্লয় করুন যা দুই উপস্থাপনাই পড়তে পারে এবং প্রযোজ্য ক্ষেত্রে নতুন উপস্থাপনায় লেখে। আলাদাভাবে পর্যালোচিত জব দিয়ে বিদ্যমান সারি ব্যাকফিল করুন, ত্রুটি ও ল্যাগ দেখুন, তারপর নতুন ফিল্ডকে প্রামাণ্য করুন। কোনো চলমান কোড পুরোনো কলাম বা কনস্ট্রেইন্ট ব্যবহার করছে না, এমন প্রমাণ পাওয়ার পরে পরের রিলিজে তা সরান।

একটি ALTER TABLE স্টেটমেন্ট তৈরির চেয়ে এই ক্রম বেশি সময় নেয়, কিন্তু ব্যর্থতা আলাদা করে। সরানোর আগে নতুন কোড খারাপ আচরণ করলে পুরোনো পথটি থাকে। ব্যাকফিল পিছিয়ে পড়লে অ্যাপ্লিকেশন রিলিজ আটকে না রেখে সেটি থামানো যায়। ডিপ্লয়মেন্ট রোলব্যাক হলে পুরোনো অ্যাপ্লিকেশনও ডেটাবেস চিনতে পারে। রোলব্যাকের সময় আগের বাইনারি এমন কলাম কোয়েরি করে যা মাইগ্রেশন ইতিমধ্যে বাদ দিয়েছে, এই আবিষ্কারের চেয়ে বাড়তি রিলিজের খরচ কম।

নাম বদলে PostgreSQL সঙ্গে সঙ্গেই নাম পরিবর্তন করে বলে বিশেষ সতর্কতা দরকার। নামটি ভালো শোনায় বলে জেনারেটর customer_ref-কে customer_id করার প্রস্তাব দিতে পারে। মাইগ্রেশন কমিট হলেই পুরোনো ইনস্ট্যান্স ব্যর্থ হবে। customer_id যোগ করুন, অ্যাপ্লিকেশন কোড বা সীমিতভাবে পর্যালোচিত ট্রিগার দিয়ে দুই ফিল্ড সমলয় রাখুন, পাঠক সরান এবং পুরোনো লেখক চলে যাওয়ার পরই customer_ref বাদ দিন। এই অস্থায়ী দ্বৈততা সরানোর শর্তসহ দৃশ্যমান ঋণ। তাৎক্ষণিক নামবদল অদৃশ্য রিলিজ নির্ভরতা।

ডিফল্ট ও নাল-বিহীন কনস্ট্রেইন্টেও লুকানো কাজ থাকে। SET NOT NULL অনুমোদনের আগে বিদ্যমান নাল গুনুন এবং সক্রিয় প্রতিটি লেখক যে মান দেয় তার প্রমাণ করুন। বড় বা ব্যস্ত টেবিলের ক্ষেত্রে PostgreSQL সংস্করণটি কনস্ট্রেইন্ট কীভাবে যাচাই করে ও কী লক নেয়, তা পর্যালোচনা করুন। বিল্ডারের উচিত প্রতিনিধিত্বমূলক ট্র্যাফিকহীন স্কিমা থেকে অনুমান না করে এই পূর্বশর্তগুলো জানানো।

ডেটা ব্যাকফিল সীমাহীন স্কিমা ট্রানজ্যাকশনের ভেতরে চালাবেন না। অনুমোদিত ওয়ার্কার দিয়ে মাপা ব্যাচে সারি আপডেট করুন, স্থিতিশীল কার্সর দিয়ে অগ্রগতি নথিবদ্ধ করুন এবং পুনরায় চেষ্টা নিরাপদ রাখুন। কোনো কাজ দুবার প্রয়োগ করলেও উদ্দেশ্যপূর্ণ অবস্থা তৈরি হলে সেটি পুনরাবৃত্তি-নিরাপদ, শুধু PostgreSQL দ্বিতীয় কোয়েরিটি গ্রহণ করলেই নয়। পরের কোড ভিন্নভাবে হিসাব করতে পারলে উদ্ভূত মানের জন্য ডেরিভেশন সংস্করণ রেকর্ড করুন।

রিলিজ প্যাকেটে চারটি সামঞ্জস্য বিন্দুর নাম থাকা উচিত:

1. মাইগ্রেশনের আগে চলতে পারা সবচেয়ে পুরোনো অ্যাপ্লিকেশন সংস্করণ।
2. পুরোনো ও নতুন দুই সংস্করণই যে স্কিমা অবস্থা গ্রহণ করে।
3. ধ্বংসাত্মক পরিষ্কার রিলিজের অনুমতি দেওয়া সংকেত।
4. ডেটা বদলানোর পর নতুন কোড রোলব্যাক হলে পুনরুদ্ধারের পথ।

এই পরিবর্তনগুলোর সময় তৈরি করা কোয়েরিতে SELECT * এড়িয়ে চলুন। কলাম যোগ করলে পুরোনো SQL পার্স হলেও স্ক্যান খরচ, ফল ডিকোড করা, অবস্থানভিত্তিক ম্যাপিং ও ডেটা প্রকাশ বদলাতে পারে। সম্পূর্ণ নামযুক্ত কলাম স্পষ্টভাবে তালিকাভুক্ত করুন এবং একই স্কিমা স্ন্যাপশট থেকে ডিকোডার তৈরি করুন। সোর্স পর্যালোচনায়ও তখন স্পষ্ট দেখা যায় ঠিক কোন ডেটা ডেটাবেসের সীমানা পার করছে।

প্রস্তুত মাইগ্রেশন টুল প্রায়ই টেবিলে প্রয়োগ করা সংস্করণ রাখে, তবে শুধু সংস্করণ নম্বর সামঞ্জস্য প্রমাণ করে না। নির্দিষ্ট SQL আর্টিফ্যাক্টের ডাইজেস্ট রেকর্ড করুন, কারণ একই পরিচিত নামের দুটি ফাইলে আলাদা কমান্ড থাকতে পারে। ইতিমধ্যে রেকর্ড হওয়া সংস্করণের ডাইজেস্ট ভিন্ন হলে এক্সিকিউটরকে তা অস্বীকার করতে হবে। প্রয়োজনীয় পূর্বসূরি না থাকলে পরের মাইগ্রেশনও অস্বীকার করতে হবে।

প্রতিটি অ্যাপ্লিকেশন ইনস্ট্যান্সকে চালুর সময় মাইগ্রেশন চালাতে দেবেন না। মাইগ্রেশন টুল অ্যাডভাইজরি লক ব্যবহার করলেও, চালু হওয়া এখন বিশেষাধিকারপ্রাপ্ত শংসাপত্র ও হেলথ চেক শেষ হওয়ার আগে স্কিমার কাজ শেষ হওয়ার ওপর নির্ভর করে। একটি রিলিজ জবে মাইগ্রেশন চালান, তার নথিবদ্ধ ফলের জন্য অপেক্ষা করুন এবং স্কিমা বদলাতে পারে না এমন পরিচয়ে রানটাইম ইনস্ট্যান্স চালু করুন। রিলিজ সিস্টেম এই ধাপগুলো আলাদা করতে না পারলে, অ্যাপ্লিকেশনকে মালিকের ক্ষমতা দেওয়ার আগে রিলিজ সিস্টেম ঠিক করুন।

শুধু গন্তব্য নয়, এই সময়রেখা পরীক্ষা করুন: পুরোনো স্কিমায় পুরোনো কোড, প্রসারিত স্কিমায় পুরোনো কোড, প্রসারিত স্কিমায় নতুন কোড এবং নতুন লেখার পর রোলব্যাক করা কোড। পরিষ্কারের আলাদা পরীক্ষা পরে হবে। এই ম্যাট্রিক্স সিনট্যাক্সগতভাবে বৈধ কিন্তু কার্যক্ষেত্রে ফিরিয়ে নেওয়া অসম্ভব পরিবর্তনগুলো ধরে।

নেতিবাচক পরীক্ষা দিয়ে সীমানা প্রমাণ করুন

নিষিদ্ধ কাজ পরীক্ষা করে ব্যর্থ না হওয়া পর্যন্ত নিরাপত্তা নকশা অসম্পূর্ণ। ডিসকভারি পরিচয়ে সংযোগ করে ইনসার্ট, টেবিল তৈরি এবং SET TRANSACTION READ WRITE চেষ্টা করুন। রানটাইম পরিচয়ে অনুমতি না থাকা টেবিলে অ্যাক্সেস, রো সিকিউরিটিতে আচ্ছাদিত ক্রস-টেন্যান্ট রিড এবং স্কিমা পরিবর্তন চেষ্টা করুন। প্রত্যাশিত ফল PostgreSQL অনুমতি ত্রুটি, এজেন্ট লগের প্রতিশ্রুতি নয়।

ইতিবাচক পরীক্ষাও চালান। ডিসকভারিকে অনুমোদিত প্রতিটি ক্যাটালগ এন্ট্রি পড়তে হবে। রানটাইমকে পুলের মাধ্যমে অনুমোদিত প্রতিটি ব্যবহারকারী কাজ করতে হবে। মাইগ্রেশন এক্সিকিউশন কেবল অনুমোদনের পথেই কাজ করবে। পণ্যের স্বাভাবিক কাজ আটকায় এমন সীমানা কোনো ঘটনার সময় কাউকে মালিকের শংসাপত্র দিয়ে তা বদলাতে প্রলুব্ধ করবে।

অ্যাপ্লিকেশন সোর্সের পাশে ছোট একটি অ্যাক্সেস চুক্তি রাখুন। তাতে ডেটাবেস, অনুমোদিত স্কিমা, ডিসকভারি পরিসর, রানটাইম অপারেশন, পুল মোড, টাইমআউট নীতি, মাইগ্রেশন অনুমোদনকারী, স্কিমা ফিঙ্গারপ্রিন্ট পদ্ধতি ও নিষিদ্ধ স্টেটমেন্টের নাম থাকবে। ধারাবাহিক পরীক্ষায় এই চুক্তির সঙ্গে বাস্তব অনুমতি তুলনা করুন। PostgreSQL অনুমতির ড্রিফট কনফিগারেশন ড্রিফট, যদিও কেউ অ্যাপ্লিকেশন কোড বদলায়নি।

রোল পরিবর্তন, নতুন টেবিল, পুনরুদ্ধার করা ডেটাবেস, পুল আপগ্রেড ও হোস্টিং পরিবর্তনের পরে আবার পরীক্ষা করুন। ভবিষ্যৎ অবজেক্টের জন্য ডিফল্ট অনুমতি গুরুত্বপূর্ণ: SELECT ON ALL TABLES বর্তমান টেবিল ঢাকে, পরে তৈরি টেবিল নয়। নতুন অবজেক্ট পর্যালোচনা না হওয়া পর্যন্ত অদৃশ্য থাকবে, নাকি সীমিতভাবে কনফিগার করা ডিফল্ট অনুমতিতে অন্তর্ভুক্ত হবে তা ঠিক করুন। আমার পছন্দ ডিফল্টভাবে অদৃশ্য রাখা, কারণ স্পষ্ট অনুমতি নতুন টেবিলকে অ্যাক্সেসের আলোচনায় আনে।

পরীক্ষা পরিকল্পনায় অনুমতি প্রত্যাহার অন্তর্ভুক্ত করুন। ডিসকভারি শংসাপত্র বন্ধ করে নিশ্চিত করুন রানটাইম ট্র্যাফিক চলছে। রানটাইম বন্ধ করে নিশ্চিত করুন মাইগ্রেশন টুলিং নীরবে তার শক্তিশালী পরিচয় বদলে ব্যবহার করছে না। এরপর সংযোগ সক্রিয় থাকা অবস্থায় প্রতিটি গোপন তথ্য ঘোরান এবং নির্ধারিত সময়ের মধ্যে পুল পুরোনো সেশন বাদ দেয় কি না দেখুন। পাসওয়ার্ড বদলালে ইতিমধ্যে প্রমাণীকৃত সেশন বন্ধ হয় না, তাই রোটেশন পদ্ধতিতে স্পষ্ট পুল রিসাইকেল বা PostgreSQL সেশন বন্ধের নীতি দরকার।

এই পরীক্ষার সময় অনিচ্ছাকৃত তথ্য প্রকাশের জন্য ব্যর্থতার বার্তা পর্যালোচনা করুন। PostgreSQL ত্রুটিতে রিলেশনের নাম, SQL-এর অংশ, কনস্ট্রেইন্টের নাম ও সরবরাহ করা মান থাকতে পারে। বিস্তারিত ত্রুটি সীমিত সার্ভার লগে পাঠান, ক্লায়েন্টকে স্থিতিশীল পাবলিক ত্রুটি দিন এবং প্রোডাকশনের সম্পূর্ণ ত্রুটি প্রবাহ কখনো এজেন্ট কথোপকথনে ফেরত দেবেন না। কোড মেরামতে বিল্ডারের স্টেটমেন্ট অবস্থান ও পরিশোধিত ডেটাবেস প্রতিক্রিয়া দরকার, গ্রাহকের মান নয়।

শেষ একটি পরীক্ষা বিস্ময়কর সংখ্যক অনিরাপদ ইন্টিগ্রেশন ধরে: মাইগ্রেশন শংসাপত্র পুরোপুরি সরিয়ে অ্যাপ্লিকেশন টেস্ট স্যুট চালান। স্বাভাবিক স্টার্টআপ, হেলথ চেক, প্রিভিউ বা রিকোয়েস্ট হ্যান্ডলিং ব্যর্থ হলে, স্কিমার মালিকানা রানটাইম পথে ঢুকে গেছে। বিল্ডারকে প্রোডাকশনে যুক্ত করার আগে সেই সংযোগ ঠিক করুন। AI অ্যাপ বিল্ডার তার মালিকানাধীন নয় এমন ডেটাবেসেও কাজ করতে পারে, কিন্তু তৈরি কোড ব্যবস্থা ভুলে গেলে PostgreSQL-কে না বলতে পারতে হবে।