بڑے لینگویج ماڈلز (LLM) ایجنٹس کے ذریعے تیار کردہ Oracle SQL اسکرپٹس کاغذ پر تو بے عیب لگ سکتے ہیں لیکن پروڈکشن میں ناکام ہو سکتے ہیں۔ 2.3 ملین لائنوں پر مشتمل ایک لیگیسی کوڈ بیس میں، ایک AI سے چلنے والا ایجنٹ مستقل طور پر ایسے آئیڈنٹیفائرز (identifiers) شامل کر دیتا تھا جو موجود ہی نہیں تھے – مثال کے طور پر، اصل STATUS_CD کالم کے بجائے POLICY_STATUS کا استعمال کرنا، یا CUSTOMER کے بجائے ایک غیر موجود CUSTOMERS ٹیبل کا حوالہ دینا۔
ٹائپو (typo) پکڑنے کے لیے اسکرپٹ کو چلانا UPDATE یا DELETE اسٹیٹمنٹس کے لیے کوئی آپشن نہیں ہے۔ انہیں پروڈکشن جیسے ڈیٹا سیٹ پر چلانے سے لاکس (locks) حاصل ہو جاتے ہیں، سیکوئنس نمبرز (sequence numbers) استعمال ہو جاتے ہیں اور اس سے دیگر اثرات (cascading side-effects) بھی پیدا ہو سکتے ہیں۔ ڈویلپرز کو ڈیٹا کو چھوئے بغیر ناموں اور سنٹیکس (syntax) کی تصدیق کرنے کا ایک طریقہ چاہیے۔ اس کا جواب، جو حیران کن طور پر سادہ ہے، Oracle کا EXPLAIN PLAN کمانڈ ہے – جسے بطور لنٹنگ (linting) مرحلہ استعمال کیا جا سکتا ہے۔
EXPLAIN PLAN ایک تیز رفتار ویلیڈیٹر کے طور پر کیسے کام کرتا ہے
جب Oracle کو کوئی اسٹیٹمنٹ موصول ہوتا ہے، تو وہ پہلے اسے پارس (parse) کرتا ہے۔ پارسنگ اس بات کی جانچ کرتی ہے کہ ہر حوالہ کردہ ٹیبل، کالم اور پرائیلیج (privilege) موجود ہے یا نہیں، پھر یہ ایک ایگزیکیوشن پلان (execution plan) بناتا ہے اور اس پلان کو سسٹم ٹیبل میں لکھ دیتا ہے۔ یہ کمانڈ اسٹیٹمنٹ کو کبھی نہیں چلاتی: کوئی بھی روز (rows) تبدیل نہیں ہوتی، کوئی ٹرگر (trigger) نہیں چلتا، اور کوئی لاک (lock) نہیں لگتا۔ اگر پارسر کو کوئی نامعلوم آبجیکٹ ملتا ہے، تو یہ چند ملی سیکنڈز میں ایرر (error) دے دیتا ہے۔
یہ طرزِ عمل EXPLAIN PLAN کو AI سے تیار کردہ SQL کے لیے ایک بہترین پری فلائٹ چیک (pre-flight check) بناتا ہے۔ کسی گمشدہ ٹیبل یا کالم کی اطلاع فوری طور پر مل جاتی ہے، جس سے جنریشن لوپ (generation loop) کو انسان کے اسکرپٹ دیکھنے سے پہلے ہی غلطی درست کرنے کا موقع مل جاتا ہے۔
وہ ورک فلو جو میں نے اپنے CI پائپ لائن میں شامل کیا
- آنے والے اسکرپٹ کو انفرادی اسٹیٹمنٹس میں تقسیم کریں۔
- ڈویلپمنٹ اسکیمہ (development schema) کے خلاف
EXPLAIN PLAN FOR <statement>چلائیں۔ - Oracle کی طرف سے واپس آنے والے کسی بھی پارسنگ ایررز کو جمع کریں۔
- دوبارہ کوشش (retry) کے لیے ان ایررز کو LLM کو واپس بھیجیں۔
عملی طور پر، ایک بار دوبارہ کوشش کرنے سے ناموں کی زیادہ تر غلطیاں دور ہو جاتی ہیں۔ AI درست اسکیمہ سیکھ لیتا ہے اور خود بخود اپنے آؤٹ پٹ کو درست کر لیتا ہے۔ میں نے ایجنٹ کو ریڈ اونلی (read-only) موڈ میں بھی لاک کر دیا ہے: یہ SELECT اور EXPLAIN PLAN کالز تو کر سکتا ہے، لیکن DDL، DML اور COMMIT بلاک کر دیے جاتے ہیں۔ یہ سینڈ باکس (sandbox) اس بات کی ضمانت دیتا ہے کہ جب تک AI اس کے ڈھانچے کی جانچ کر رہا ہے، ڈیٹا کو ہاتھ نہ لگایا جائے۔
ناموں کی جانچ کے علاوہ، تیار کردہ پلان کارکردگی کے واضح خطرات (performance red flags) کو بھی ظاہر کرتا ہے۔ اگر کوئی اسٹیٹمنٹ کسی بہت بڑی ٹیبل پر فل ٹیبل اسکین (full-table scan) کا باعث بننے والی ہو، تو پلان کسی بھی ڈیٹا کو چھونے سے پہلے ہی اسے دکھا دیتا ہے، جس سے ڈویلپرز کو انڈیکس تجویز کرنے یا پریڈیکیٹ (predicate) کو دوبارہ لکھنے کا موقع مل جاتا ہے۔
اس طریقہ کار کی حدود
- منطقی درستگی (Logical correctness) کی تصدیق نہیں ہوتی۔ ایک ایسا اسٹیٹمنٹ جو صحیح کالمز کا حوالہ دیتا ہے لیکن غلط فلٹر استعمال کرتا ہے، وہ بھی لنٹ (lint) پاس کر لیتا ہے۔
- PL/SQL بلاکس اس کے دائرہ کار سے باہر ہیں۔ پارسر صرف انفرادی SQL اسٹیٹمنٹس کو ہینڈل کرتا ہے؛ پروسیجرل کوڈ (procedural code) کے لیے الگ ویلیڈیشن کی ضرورت ہوتی ہے۔
- ڈیٹا لیول کی ویلیڈیشن موجود نہیں ہے۔ لنٹ آپ کو یہ نہیں بتا سکتا کہ آیا کوئی لٹرل ویلیو (literal value) کالم کے ڈومین (domain) کے مطابق ہے یا آیا کوئی فارن کی (foreign-key) حوالہ حقیقت میں موجود ہے۔
- صرف ڈویلپمنٹ اسکیمہ۔ وہ غلطیاں جو صرف پروڈکشن میں ظاہر ہوتی ہیں – مثال کے طور پر، ایک ٹیبل جو ڈویلپمنٹ میں موجود ہے لیکن پروڈکشن میں اس کا نام بدل دیا گیا ہے – وہ بعد تک نظر نہیں آتیں۔
یہ خامیاں اس طریقے کی افادیت کو کم نہیں کرتیں؛ یہ صرف اس کی حدود کا تعین کرتی ہیں۔ زیادہ تر LLM سے تیار کردہ DML اسکرپٹس کے لیے، سب سے عام ناکامی ٹائپو یا غلط آبجیکٹ کا نام ہونا ہے، اور EXPLAIN PLAN بالکل یہی چیز پکڑتا ہے۔
دیگر ڈیٹا بیس انجنوں تک منتقلی (Portability)
یہی اصول Oracle سے ہٹ کر بھی لاگو ہوتا ہے۔ PostgreSQL کا PREPARE اسٹیٹمنٹ یا EXPLAIN ایگزیکیوشن کے بغیر کوئری کو پارس کر سکتا ہے۔ SQL Server SET PARSEONLY ON کی پیشکش کرتا ہے، جو انجن کو اصل پروسیسنگ کو چھوڑ کر صرف سنٹیکس اور آبجیکٹ کے ناموں کی تصدیق کرنے پر مجبور کرتا ہے۔ کوئی بھی RDBMS جو پارسنگ کو ایگزیکیوشن سے الگ کرتا ہے، وہ ایک ہلکا پھلکا لنٹنگ گیٹ (linting gate) بن سکتا ہے۔
خلاصہ
ہر AI سے تیار کردہ SQL اسٹیٹمنٹ پر EXPLAIN PLAN (یا اس کے مساوی) چلانے سے ڈیٹا بیس پارسر ایک سستا اور بغیر کسی خطرے والا لنٹنگ گیٹ بن جاتا ہے۔ یہ ڈیٹا میں تبدیلی سے پہلے ہی ناموں اور سنٹیکس کی سب سے زیادہ ہونے والی غلطیوں کو پکڑ لیتا ہے، جس سے لیگیسی سسٹمز مستحکم رہتے ہیں اور ڈویلپرز LLM کی مدد سے کوڈنگ کے ذریعے پیدا ہونے والی پیداواری صلاحیت سے فائدہ اٹھا سکتے ہیں۔