લાર્જ-લેંગ્વેજ-મોડલ (LLM) એજન્ટ્સ દ્વારા તૈયાર કરવામાં આવેલા Oracle SQL સ્ક્રિપ્ટ્સ કાગળ પર ભૂલરહિત દેખાઈ શકે છે, પરંતુ પ્રોડક્શનમાં તે મોટી સમસ્યાઓ ઊભી કરી શકે છે. 2.3 મિલિયન-લાઇન ધરાવતા લેગસી કોડબેઝમાં, એક AI-સંચાલિત એજન્ટ વારંવાર એવા આઇડેન્ટિફાયર્સ (identifiers) ઉમેરી દેતું હતું જે અસ્તિત્વમાં નહોતા – ઉદાહરણ તરીકે, સાચા STATUS_CD કોલમ ને બદલે POLICY_STATUS નો ઉપયોગ કરવો, અથવા CUSTOMER ને બદલે અસ્તિત્વમાં ન હોય તેવી CUSTOMERS ટેબલનો ઉલ્લેખ કરવો.
UPDATE અથવા DELETE સ્ટેટમેન્ટ્સમાં ટાઈપો (typo) પકડવા માટે સ્ક્રિપ્ટ ચલાવવી એ કોઈ વિકલ્પ નથી. પ્રોડક્શન જેવા ડેટાસેટ પર તેને એક્ઝિક્યુટ કરવાથી લોક્સ (locks) લાગે છે, સિક્વન્સ નંબર્સ વપરાઈ જાય છે અને તેનાથી અન્ય ગંભીર અસરો (cascading side-effects) થઈ શકે છે. ડેવલપર્સને ડેટાને અડ્યા વગર નામ અને સિન્ટેક્સ (syntax) ને વેલિડેટ કરવાની જરૂર છે. આનો જવાબ, જે આશ્ચર્યજનક રીતે સરળ છે, તે Oracle ની EXPLAIN PLAN કમાન્ડ છે – જેને લિન્ટિંગ (linting) સ્ટેપ તરીકે ફરીથી ઉપયોગમાં લેવામાં આવે છે.
EXPLAIN PLAN ઝડપી વેલિડેટર તરીકે કેવી રીતે કામ કરે છે
જ્યારે Oracle ને કોઈ સ્ટેટમેન્ટ મળે છે, ત્યારે તે પહેલા તેને પાર્સ (parse) કરે છે. પાર્સિંગ એ તપાસે છે કે સંદર્ભિત દરેક ટેબલ, કોલમ અને પ્રિવિલેજ (privilege) અસ્તિત્વમાં છે કે નહીં, ત્યારબાદ તે એક્ઝિક્યુશન પ્લાન બનાવે છે અને તે પ્લાનને સિસ્ટમ ટેબલમાં લખે છે. આ કમાન્ડ ક્યારેય સ્ટેટમેન્ટને રન કરતું નથી: કોઈ રો (row) માં ફેરફાર થતો નથી, કોઈ ટ્રિગર્સ (triggers) ફાયર થતા નથી, અને કોઈ લોક્સ લેવામાં આવતા નથી. જો પાર્સરને કોઈ અજાણ્યું ઓબ્જેક્ટ મળે, તો તે થોડી મિલીસેકન્ડોમાં ભૂલ (error) દર્શાવે છે.
આ વર્તણૂક EXPLAIN PLAN ને AI-જનરેટેડ SQL માટે એક પરફેક્ટ પ્રી-ફ્લાઇટ ચેક (pre-flight check) બનાવે છે. ટેબલ અથવા કોલમ ખૂટે તો તે તરત જ રિપોર્ટ થાય છે, જેનાથી જનરેશન લૂપ માનવી સ્ક્રિપ્ટ જોતા પહેલા જ ભૂલ સુધારી શકે છે.
જે વર્કફ્લો મેં મારા CI પાઇપલાઇનમાં સેટ કર્યો છે
- આવતી સ્ક્રિપ્ટને અલગ-અલગ સ્ટેટમેન્ટ્સમાં વિભાજિત (Split) કરો.
- ડેવલપમેન્ટ સ્કીમા સામે
EXPLAIN PLAN FOR <statement>ચલાવો (Run). - Oracle દ્વારા રિટર્ન કરવામાં આવેલી કોઈપણ પાર્સિંગ ભૂલોને કલેક્ટ (Collect) કરો.
- ફરીથી પ્રયાસ કરવા માટે તે ભૂલોને LLM ને ફરીથી મોકલો (Feed).
વ્યવહારમાં, એક જ રિટ્રાય (retry) મોટાભાગની નામકરણની ભૂલોને દૂર કરી દે છે. AI સાચી સ્કીમા શીખી જાય છે અને તેના આઉટપુટને આપમેળે એડજસ્ટ કરે છે. મેં એજન્ટને રીડ-ઓન્લી (read-only) મોડમાં પણ લોક કર્યો છે: તે SELECT અને EXPLAIN PLAN કોલ્સ કરી શકે છે, પરંતુ DDL, DML અને COMMIT બ્લોક કરવામાં આવે છે. આ સેન્ડબોક્સ (sandbox) ખાતરી આપે છે કે જ્યારે AI તેની સ્ટ્રક્ચર તપાસતું હોય ત્યારે ડેટાબેઝ અસ્પૃશ્ય રહે.
નામની તપાસ સિવાય, જનરેટ થયેલ પ્લાન સ્પષ્ટ પર્ફોર્મન્સ રેડ ફ્લેગ્સ (performance red flags) પણ દર્શાવે છે. જો કોઈ સ્ટેટમેન્ટ વિશાળ ટેબલ પર ફૂલ-ટેબલ સ્કેન (full-table scan) ટ્રિગર કરશે, તો પ્લાન કોઈપણ રો ને અડતા પહેલા જ તે બતાવે છે, જેનાથી ડેવલપર્સને ઇન્ડેક્સ સૂચવવાની અથવા પ્રિડિકેટ (predicate) ને ફરીથી લખવાની તક મળે છે.
આ અભિગમની મર્યાદાઓ
- લોજિકલ કરેક્ટનેસ (Logical correctness) વેરીફાય થતી નથી. એવું સ્ટેટમેન્ટ જે સાચા કોલમનો સંદર્ભ આપે છે પરંતુ ખોટો ફિલ્ટર લાગુ કરે છે, તે પણ લિન્ટમાં પાસ થઈ જાય છે.
- PL/SQL બ્લોક્સ આ સ્કોપની બહાર છે. પાર્સર ફક્ત વ્યક્તિગત SQL સ્ટેટમેન્ટ્સને હેન્ડલ કરે છે; પ્રોસિજરલ કોડ માટે અલગ વેલિડેશન પાથની જરૂર છે.
- ડેટા-લેવલ વેલિડેશન ખૂટે છે. લિન્ટ તમને એ નથી જણાવી શકતું કે લિટરલ વેલ્યુ (literal value) કોલમના ડોમેન સાથે સુસંગત છે કે નહીં અથવા ફોરેન-કી (foreign-key) રેફરન્સ ખરેખર અસ્તિત્વમાં છે કે નહીં.
- માત્ર ડેવ સ્કીમા. જે ભૂલો ફક્ત પ્રોડક્શનમાં દેખાય છે – ઉદાહરણ તરીકે, એક ટેબલ જે ડેવમાં છે પરંતુ પ્રોડક્શનમાં તેનું નામ બદલવામાં આવ્યું છે – તે પછીથી તપાસ ન થાય ત્યાં સુધી અદ્રશ્ય રહે છે.
આ ખામીઓ પદ્ધતિની ઉપયોગિતા ઘટાડતી નથી; તે ફક્ત તેની સીમાઓ નક્કી કરે છે. મોટાભાગના LLM-જનરેટેડ DML સ્ક્રિપ્ટ્સ માટે, સૌથી સામાન્ય નિષ્ફળતાનું કારણ ટાઈપો અથવા ખોટું ઓબ્જેક્ટ નામ હોય છે, અને EXPLAIN PLAN બરાબર તે જ પકડે છે.
અન્ય ડેટાબેઝ એન્જિનમાં પોર્ટેબિલિટી
આ જ સિદ્ધાંત Oracle સિવાય પણ લાગુ પડે છે. PostgreSQL નું PREPARE સ્ટેટમેન્ટ અથવા EXPLAIN એક્ઝિક્યુશન વગર ક્વેરીને પાર્સ કરી શકે છે. SQL Server SET PARSEONLY ON ઓફર કરે છે, જે એન્જિનને વાસ્તવિક પ્રોસેસિંગને સ્કીપ કરીને સિન્ટેક્સ અને ઓબ્જેક્ટ નામોને વેલિડેટ કરવા માટે મજબૂર કરે છે. કોઈપણ RDBMS જે પાર્સિંગને એક્ઝિક્યુશનથી અલગ કરે છે તે લાઈટવેઈટ લિન્ટિંગ ગેટ (linting gate) બની શકે છે.
મુખ્ય વાત (Takeaway)
દરેક AI-જનરેટેડ SQL સ્ટેટમેન્ટ પર EXPLAIN PLAN (અથવા તેના સમાન) ચલાવવાથી ડેટાબેઝ પાર્સર એક સસ્તું, શૂન્ય-જોખમ ધરાવતું લિન્ટિંગ ગેટ બની જાય છે. તે કોઈપણ ડેટા હલતા પહેલા સૌથી વારંવાર થતી નામકરણ અને સિન્ટેક્સની ભૂલોને પકડી લે છે, જેનાથી લેગસી સિસ્ટમ્સ સ્થિર રહે છે અને ડેવલપર્સને LLM-આધારિત કોડિંગનો ઉત્પાદકતા વધારો મેળવવામાં મદદ મળે છે.