Large-language-model (LLM) agents ਦੁਆਰਾ ਤਿਆਰ ਕੀਤੇ ਗਏ Oracle SQL ਸਕ੍ਰਿਪਟ ਕਾਗਜ਼ 'ਤੇ ਬਿਲਕੁਲ ਸਹੀ ਲੱਗ ਸਕਦੇ ਹਨ, ਪਰ ਫਿਰ ਵੀ production ਵਿੱਚ ਫੇਲ ਹੋ ਸਕਦੇ ਹਨ। 2.3 ਮਿਲੀਅਨ-ਲਾਈਨ ਦੇ ਇੱਕ legacy codebase ਵਿੱਚ, ਇੱਕ AI-driven agent ਲਗਾਤਾਰ ਅਜਿਹੇ identifiers ਦੀ ਵਰਤੋਂ ਕਰ ਰਿਹਾ ਸੀ ਜੋ ਮੌਜੂਦ ਹੀ ਨਹੀਂ ਸਨ – ਉਦਾਹਰਨ ਲਈ, ਅਸਲੀ STATUS_CD ਕਾਲਮ ਦੀ ਬਜਾਏ POLICY_STATUS ਦੀ ਵਰਤੋਂ ਕਰਨਾ, ਜਾਂ CUSTOMER ਦੀ ਬਜਾਏ ਇੱਕ ਗੈਰ-ਮੌਜੂਦ CUSTOMERS table ਦਾ ਹਵਾਲਾ ਦੇਣਾ।
UPDATE ਜਾਂ DELETE ਸਟੇਟਮੈਂਟਾਂ ਲਈ ਟਾਈਪੋ (typo) ਫੜਨ ਲਈ ਸਕ੍ਰਿਪਟ ਚਲਾਉਣਾ ਕੋਈ ਵਿਕਲਪ ਨਹੀਂ ਹੈ। ਇੱਕ production-like dataset 'ਤੇ ਉਹਨਾਂ ਨੂੰ ਚਲਾਉਣ ਨਾਲ locks ਲੱਗ ਜਾਂਦੇ ਹਨ, sequence numbers ਖ਼ਤਮ ਹੋ ਜਾਂਦੇ ਹਨ ਅਤੇ ਕਸਕੇਡਿੰਗ (cascading) ਸਾਈਡ-ਇਫੈਕਟਸ ਹੋ ਸਕਦੇ ਹਨ। ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਕਿਸੇ ਵੀ ਡੇਟਾ ਨੂੰ ਛੇੜੇ ਬਿਨਾਂ ਨਾਮ ਅਤੇ syntax ਨੂੰ ਵੈਲੀਡੇਟ ਕਰਨ ਦਾ ਤਰੀਕਾ ਚਾਹੀਦਾ ਹੈ। ਇਸਦਾ ਜਵਾਬ, ਜੋ ਕਿ ਹੈਰਾਨੀਜਨਕ ਤੌਰ 'ਤੇ ਸਰਲ ਹੈ, Oracle ਦਾ EXPLAIN PLAN ਕਮਾਂਡ ਹੈ – ਜਿਸ ਨੂੰ ਇੱਕ linting ਸਟੈਪ ਵਜੋਂ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ।
EXPLAIN PLAN ਇੱਕ ਤੇਜ਼ ਵੈਲੀਡੇਟਰ ਵਜੋਂ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ
ਜਦੋਂ Oracle ਨੂੰ ਕੋਈ ਸਟੇਟਮੈਂਟ ਮਿਲਦੀ ਹੈ, ਤਾਂ ਇਹ ਪਹਿਲਾਂ ਇਸਨੂੰ parse ਕਰਦਾ ਹੈ। Parsing ਇਹ ਚੈੱਕ ਕਰਦਾ ਹੈ ਕਿ ਹਰ ਹਵਾਲਾ ਦਿੱਤੀ ਗਈ table, column ਅਤੇ privilege ਮੌਜੂਦ ਹੈ ਜਾਂ ਨਹੀਂ, ਫਿਰ ਇਹ ਇੱਕ execution plan ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਉਸ plan ਨੂੰ ਇੱਕ system table ਵਿੱਚ ਲਿਖਦਾ ਹੈ। ਇਹ ਕਮਾਂਡ ਸਟੇਟਮੈਂਟ ਨੂੰ ਕਦੇ ਵੀ ਚਲਾਉਂਦੀ ਨਹੀਂ ਹੈ: ਕੋਈ ਵੀ row ਮੋਡੀਫਾਈ ਨਹੀਂ ਹੁੰਦੀ, ਕੋਈ trigger ਫਾਇਰ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ਕੋਈ lock ਨਹੀਂ ਲੱਗਦਾ। ਜੇਕਰ parser ਨੂੰ ਕੋਈ ਅਣਜਾਣ object ਮਿਲਦਾ ਹੈ, ਤਾਂ ਇਹ ਕੁਝ ਮਿਲੀਸੈਕਿੰਡਾਂ ਵਿੱਚ ਇੱਕ error ਦਿੰਦਾ ਹੈ।
ਇਹ ਵਿਵਹਾਰ EXPLAIN PLAN ਨੂੰ AI-generated SQL ਲਈ ਇੱਕ ਸੰਪੂਰਨ pre-flight check ਬਣਾਉਂਦਾ ਹੈ। ਕਿਸੇ missing table ਜਾਂ column ਦੀ ਰਿਪੋਰਟ ਤੁਰੰਤ ਮਿਲ ਜਾਂਦੀ ਹੈ, ਜਿਸ ਨਾਲ generation loop ਨੂੰ ਇਨਸਾਨ ਦੇ ਸਕ੍ਰਿਪਟ ਦੇਖਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਗਲਤੀ ਸੁਧਾਰਨ ਦਾ ਮੌਕਾ ਮਿਲ ਜਾਂਦਾ ਹੈ।
ਉਹ workflow ਜੋ ਮੈਂ ਆਪਣੇ CI pipeline ਵਿੱਚ ਜੋੜਿਆ ਹੈ
- ਆ ਰਹੀ ਸਕ੍ਰਿਪਟ ਨੂੰ ਵੱਖ-ਵੱਖ ਸਟੇਟਮੈਂਟਾਂ ਵਿੱਚ Split ਕਰੋ।
- ਇੱਕ development schema ਦੇ ਵਿਰੁੱਧ
EXPLAIN PLAN FOR <statement>Run ਕਰੋ। - Oracle ਦੁਆਰਾ ਵਾਪਸ ਕੀਤੇ ਗਏ ਕਿਸੇ ਵੀ parsing error ਨੂੰ Collect ਕਰੋ।
- ਗਲਤੀਆਂ ਨੂੰ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ (retry) ਕਰਨ ਲਈ LLM ਨੂੰ Feed ਕਰੋ।
ਅਸਲ ਵਿੱਚ, ਇੱਕ ਵਾਰ ਦੀ retry ਜ਼ਿਆਦਾਤਰ naming errors ਨੂੰ ਸਾਫ਼ ਕਰ ਦਿੰਦੀ ਹੈ। AI ਸਹੀ schema ਸਿੱਖ ਲੈਂਦਾ ਹੈ ਅਤੇ ਆਪਣੇ output ਨੂੰ ਆਪਣੇ ਆਪ ਐਡਜਸਟ ਕਰ ਲੈਂਦਾ ਹੈ। ਮੈਂ agent ਨੂੰ read-only mode ਵਿੱਚ ਵੀ lock ਕਰ ਦਿੰਦਾ ਹਾਂ: ਇਹ SELECTs ਅਤੇ EXPLAIN PLAN calls ਜਾਰੀ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ DDL, DML ਅਤੇ COMMIT ਨੂੰ ਰੋਕ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਉਹ sandbox ਇਹ ਗਾਰੰਟੀ ਦਿੰਦਾ ਹੈ ਕਿ ਜਦੋਂ AI ਇਸਦੇ structure ਦੀ ਜਾਂਚ ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹੈ, ਤਾਂ database ਅਛੂਤਾ ਰਹਿੰਦਾ ਹੈ।
ਨਾਮਾਂ ਦੀ ਜਾਂਚ ਤੋਂ ਇਲਾਵਾ, ਤਿਆਰ ਕੀਤਾ ਗਿਆ plan ਸਪੱਸ਼ਟ performance red flags ਨੂੰ ਵੀ ਦਰਸਾਉਂਦਾ ਹੈ। ਜੇਕਰ ਕੋਈ ਸਟੇਟਮੈਂਟ ਕਿਸੇ ਵੱਡੀ table 'ਤੇ full-table scan ਨੂੰ trigger ਕਰੇਗੀ, ਤਾਂ plan ਕਿਸੇ ਵੀ row ਨੂੰ ਛੇੜਨ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਇਸਨੂੰ ਦਿਖਾ ਦਿੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਡਿਵੈਲਪਰਾਂ ਨੂੰ indexes ਸੁਝਾਉਣ ਜਾਂ predicate ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ ਦਾ ਮੌਕਾ ਮਿਲਦਾ ਹੈ।
ਇਸ ਪਹੁੰਚ ਦੀਆਂ ਸੀਮਾਵਾਂ
- Logical correctness ਦੀ ਜਾਂਚ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ। ਇੱਕ ਸਟੇਟਮੈਂਟ ਜੋ ਸਹੀ columns ਦਾ ਹਵਾਲਾ ਦਿੰਦੀ ਹੈ ਪਰ ਗਲਤ filter ਲਗਾਉਂਦੀ ਹੈ, ਉਹ ਫਿਰ ਵੀ lint ਵਿੱਚ ਪਾਸ ਹੋ ਜਾਂਦੀ ਹੈ।
- PL/SQL blocks ਇਸਦੇ ਦਾਇਰੇ ਤੋਂ ਬਾਹਰ ਹਨ। Parser ਸਿਰਫ਼ ਵੱਖ-ਵੱਖ SQL ਸਟੇਟਮੈਂਟਾਂ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ; procedural code ਲਈ ਇੱਕ ਵੱਖਰੇ validation path ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
- Data-level validation ਦੀ ਕਮੀ ਹੈ। Lint ਤੁਹਾਨੂੰ ਇਹ ਨਹੀਂ ਦੱਸ ਸਕਦਾ ਕਿ ਕੋਈ literal value ਕਿਸੇ column ਦੇ domain ਦੇ ਅਨੁਕੂਲ ਹੈ ਜਾਂ ਕੀ ਕੋਈ foreign-key reference ਅਸਲ ਵਿੱਚ ਮੌਜੂਦ ਹੈ।
- ਸਿਰਫ਼ Dev schema। ਉਹ ਗਲਤੀਆਂ ਜੋ ਸਿਰਫ਼ production ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ – ਉਦਾਹਰਨ ਲਈ, ਇੱਕ table ਜੋ dev ਵਿੱਚ ਮੌਜੂਦ ਹੈ ਪਰ prod ਵਿੱਚ ਇਸਦਾ ਨਾਮ ਬਦਲ ਦਿੱਤਾ ਗਿਆ ਹੈ – ਬਾਅਦ ਤੱਕ ਅਣਡਿੱਠੀਆਂ ਰਹਿ ਜਾਂਦੀਆਂ ਹਨ।
ਇਹ ਕਮੀਆਂ ਇਸ ਵਿਧੀ ਦੀ ਉਪਯੋਗਤਾ ਨੂੰ ਘੱਟ ਨਹੀਂ ਕਰਦੀਆਂ; ਉਹ ਸਿਰਫ਼ ਇਸਦੀ ਸੀਮਾ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੀਆਂ ਹਨ। ਜ਼ਿਆਦਾਤਰ LLM-generated DML scripts ਲਈ, ਸਭ ਤੋਂ ਆਮ ਅਸਫਲਤਾ ਦਾ ਕਾਰਨ ਟਾਈਪੋ ਜਾਂ ਗਲਤ object name ਹੁੰਦਾ ਹੈ, ਅਤੇ EXPLAIN PLAN ਬਿਲਕੁਲ ਇਹੀ ਫੜਦਾ ਹੈ।
ਹੋਰ database engines ਤੱਕ ਪੋਰਟੇਬਿਲਟੀ
ਇਹੀ ਸਿਧਾਂਤ Oracle ਤੋਂ ਇਲਾਵਾ ਹੋਰਨਾਂ 'ਤੇ ਵੀ ਲਾਗੂ ਹੁੰਦਾ ਹੈ। PostgreSQL ਦਾ PREPARE statement ਜਾਂ EXPLAIN execution ਤੋਂ ਬਿਨਾਂ query ਨੂੰ parse ਕਰ ਸਕਦਾ ਹੈ। SQL Server SET PARSEONLY ON ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ, ਜੋ engine ਨੂੰ ਅਸਲ processing ਨੂੰ ਛੱਡ ਕੇ syntax ਅਤੇ object names ਨੂੰ ਵੈਲੀਡੇਟ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ। ਕੋਈ ਵੀ RDBMS ਜੋ parsing ਨੂੰ execution ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ, ਇੱਕ ਹਲਕਾ (lightweight) linting gate ਬਣ ਸਕਦਾ ਹੈ।
ਸਿੱਖ (Takeaway)
ਹਰ AI-generated SQL ਸਟੇਟਮੈਂਟ 'ਤੇ EXPLAIN PLAN (ਜਾਂ ਇਸਦੇ ਬਰਾਬਰ) ਚਲਾਉਣ ਨਾਲ ਇੱਕ database parser ਇੱਕ ਸਸਤੇ, zero-risk linting gate ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ। ਇਹ ਕਿਸੇ ਵੀ ਡੇਟਾ ਦੇ ਹਿੱਲਣ ਤੋਂ ਪਹਿਲਾਂ ਸਭ ਤੋਂ ਆਮ naming ਅਤੇ syntax errors ਨੂੰ ਫੜ ਲੈਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ legacy systems ਸਥਿਰ ਰਹਿੰਦੇ ਹਨ ਅਤੇ ਡਿਵੈਲਪਰਾਂ ਨੂੰ LLM-assisted coding ਦੀ ਉਤਪਾਦਕਤਾ (productivity) ਦਾ ਲਾਭ ਮਿਲਦਾ ਹੈ।