CRUD ऑपरेशन्स

यह क्यों ज़रूरी है

Data के कई defects असल में CRUD defects होते हैं: form जो field स्वीकार करता है वह कभी save नहीं होता, edit गलत record बदल देता है या ऐसा field मिटा देता है जिसे किसी ने छुआ नहीं, delete related rows पीछे छोड़ देता है या ज़रूरत से ज़्यादा मिटा देता है। Screen अक्सर इन्हें छिपा लेती है: हरा "Saved" message सिर्फ़ इतना साबित करता है कि request बिना error के ख़त्म हुई, यह नहीं कि सही data सही row तक पहुँचा।

CRUD एक आसान coverage checklist भी है। Feature जिस भी तरह के records संभालता है, हर एक के लिए पूछें: क्या चारों operations मौजूद हैं, हर operation कौन कर सकता है, और क्या हर एक टेस्ट हुआ? Create और read लगभग हर test में चल जाते हैं, क्योंकि बाकी tests को data चाहिए; update और delete तभी टेस्ट होते हैं जब कोई उनकी planning करे, और यही वे operations हैं जो data खो सकते हैं या उजागर कर सकते हैं।

चार operations और हर एक से क्या अपेक्षा है

हर operation का stored data पर एक अपेक्षित असर होता है, और वही असर आप टेस्ट करते हैं। पिछले lesson की primary key चारों को जोड़ती है: create record को उसकी key देता है; read, update और delete उसी से ठीक एक record तक पहुँचते हैं।

• Create: नई primary key के साथ एक नया record, हर भेजा गया field सही column में, और वे values जो system ख़ुद set करता है, जैसे default status और created_at।
• Read: stored data जैसा है वैसा लौटता है, key से एक record या filtered list, और read कुछ नहीं बदलता।
• Update: intended record के intended fields बदलते हैं, बाकी सब वैसा ही रहता है, और table में updated_at हो तो वह आगे बढ़ता है।
• Delete: record product से गायब हो जाता है। Database में वह या तो हटा दिया जाता है (hard delete), या रखकर mark किया जाता है, जैसे deleted_at timestamp से (soft delete)। जिस row को दूसरी rows refer करती हैं, उसका hard delete पिछले lesson के foreign key delete rule के मुताबिक चलता है: related rows भी delete होती हैं (CASCADE), उनका reference NULL करके उन्हें रखा जाता है (SET NULL), या delete reject होता है (RESTRICT या NO ACTION)। Soft delete असल में एक update है, इसलिए कोई delete rule नहीं चलता और related rows को application को ख़ुद handle करना पड़ता है।

एक operation, तीन layers: UI, HTTP और SQL

UI में click API को HTTP request भेजता है, और API एक या ज़्यादा SQL statements चलाता है। HTTP request में एक method होता है, यानी action, और एक path, यानी target: GET /contacts/7 contact 7 माँगता है, और response में 200 OK जैसा status code आता है। PUT पूरा नया record भेजता है, PATCH सिर्फ़ बदलने वाले fields। SQL की तरफ़ INSERT rows जोड़ता है, SELECT rows पढ़ता है, UPDATE मौजूदा rows की values बदलता है और DELETE rows हटाता है; WHERE clause statement को सिर्फ़ उन rows तक सीमित करता है जो उसकी condition से match होती हैं।

REST API में, यानी उस आम style में जहाँ हर path किसी record या records के collection का नाम होता है, आम mapping यह है: create के लिए POST और INSERT, read के लिए GET और SELECT, update के लिए PUT या PATCH और UPDATE, और delete के लिए दोनों layers में DELETE। ये चार statements उस हिस्से का मूल हैं जिसे आम तौर पर SQL की data manipulation language (DML) कहा जाता है। HTTP methods और REST API basics वाले lessons requests को गहराई से सिखाते हैं, और अगला lesson SELECT सिखाता है।

यह mapping एक convention है, नियम नहीं, और जहाँ यह अलग होती है वहीं tests को देखना चाहिए। एक POST /orders order के लिए एक INSERT और हर item के लिए एक INSERT चला सकता है। Delete button ऐसा UPDATE चला सकता है जो deleted_at set करे; RFC 9110 DELETE को URI और resource के बीच का संबंध हटाने के रूप में परिभाषित करता है, data मिटाने के वादे के रूप में नहीं। Cancel button POST /appointments/7/cancel भेज सकता है, जो CRUD की भाषा में update है। असल में क्या होता है, यह API contract, developer या database बताता है।

CRUD    UI action        HTTP request        SQL statement
------  ---------------  ------------------  --------------------------------------------
Create  Add contact      POST /contacts      INSERT INTO contacts (...) VALUES (...)
Read    Open contact 7   GET /contacts/7     SELECT * FROM contacts WHERE id = 7
Update  Edit phone       PATCH /contacts/7   UPDATE contacts SET phone = ... WHERE id = 7
Delete  Delete contact   DELETE /contacts/7  DELETE FROM contacts WHERE id = 7

आज़माएँ: SQL INSERT जनरेटर

पहले product में verify करें, फिर database में

हर operation वैसे करें जैसे user या client करता है, UI या API के ज़रिए। Database में सीधे rows लिखना उस validation और logic को छोड़ देता है जिसे आपको टेस्ट करना है; सीधे INSERT statements preconditions तैयार करने के लिए हैं। फिर नीचे दिए points पर नतीजा जाँचें। Negative tests में, जैसे invalid input या बिना permission वाला user, database में कोई बदलाव नहीं दिखना चाहिए, आधी-अधूरी row भी नहीं।

सुरक्षित तरीके से काम करें: जाँच के लिए SELECT इस्तेमाल करें, और INSERT, UPDATE या DELETE सिर्फ़ उस test environment में चलाएँ जिसे बदलने की आपको अनुमति है, production में स्पष्ट अनुमति के बिना कभी नहीं। WHERE clause के बिना UPDATE या DELETE table की हर row बदल देता है, इसलिए पहले WHERE लिखें और उसे SELECT में चलाकर देखें कि कौन-सी rows match होती हैं।

• Response: screen पर message, या API से मिला status code और body।
• Product के ज़रिए read-back: page reload करें या अलग GET भेजें। इससे सिर्फ़ आपका input दोहराने वाली screen और पुराना cached data पकड़ में आता है; update से पहले और बाद के response की तुलना हर बदला हुआ field दिखाती है।
• Database: row को उसकी primary key से select करें और वह देखें जो product शायद न दिखाए: field mapping, default values, timestamps, soft-delete flags, rounding और Arabic text की encoding।
• आस-पास की rows: create ने ठीक एक row जोड़ी; update ने दूसरी rows और न छुए गए columns नहीं बदले; delete ने related rows design के मुताबिक handle कीं, और record lists, search और totals से गायब है।

आज़माएँ: REST API टेस्टर आज़माएँ: JSON डिफ़ आज़माएँ: SQL क्वेरी वैलिडेटर

Worked example: appointment reschedule करना

Requirement: "Patient किसी आने वाले appointment को उसी doctor के किसी दूसरे खाली slot पर ले जा सकता है। पुराना slot फिर से खाली हो जाता है।" User के लिए यह एक update है; database में दो tables बदलनी चाहिए।

Tester पहले state नोट करता है: patient 1203 का appointment 7, slot 41 में 09:00 बजे है, और यह उस patient का अकेला booked appointment है। फिर वह UI में उसे 10:30 पर reschedule करता है, जो PATCH भेजता है, "My appointments" reload करता है, जहाँ 10:30 दिखना चाहिए, और इस section के अंत की queries चलाता है। हर query को "match होने वाली rows के ये columns दिखाओ" की तरह पढ़ें: IN (41, 58) दोनों में से किसी भी id से match करता है, और COUNT(*) match होने वाली rows की गिनती लौटाता है। हर query एक अलग defect पकड़ती है:

• Query 1: अगर status या patient_id बदल गया, तो update ने ऐसे columns छुए जो उसे नहीं छूने थे; अगर slot_id अब भी 41 है, तो confirmation screen ने सिर्फ़ भेजा गया data दिखाया।
• Query 2: अगर slot 41 अब भी booked है, तो कोई भी 09:00 फिर से book नहीं कर पाएगा; अगर slot 58 booked mark नहीं हुआ, तो कोई दूसरा patient भी 10:30 book कर सकता है। Patient को कुछ गलत नहीं दिखता; यह सिर्फ़ database में या किसी दूसरे patient के view में दिखता है।
• Query 3: अगर API ने row 7 update करने की जगह नया appointment insert किया, तो count 2 है, यानी ऐसी double booking जो confirmation screen नहीं दिखाएगी।

-- Before: appointment 7 (patient 1203) is booked in slot 41 at 09:00
-- UI: "Reschedule" to 10:30 -> PATCH /api/appointments/7 {"slot_id": 58} -> 200 OK

-- 1. The appointment changed, and only the intended columns
SELECT id, patient_id, slot_id, status, updated_at
FROM appointments
WHERE id = 7;
-- expected: slot_id 58, patient_id 1203, status 'booked', updated_at later

-- 2. Both slots changed
SELECT id, starts_at, is_booked
FROM slots
WHERE id IN (41, 58);
-- expected: 41 is_booked false, 58 is_booked true

-- 3. No second appointment was created
SELECT COUNT(*)
FROM appointments
WHERE patient_id = 1203 AND status = 'booked';
-- expected: 1, the same as before

आज़माएँ: SQL फ़ॉर्मेटर

अक्सर पूछे जाने वाले सवाल

संदर्भ

• RFC 9110: HTTP SemanticsIETF · 2022HTTP मेथड, हेडर फ़ील्ड, स्टेटस कोड और कंटेंट निगोशिएशन के अर्थ, वायर वर्ज़न से स्वतंत्र।
• ISO/IEC 9075-1:2023 — Information technology — Database languages SQL — Part 1: Framework (SQL/Framework)ISO/IEC · 2023अंतरराष्ट्रीय SQL मानक का framework भाग, जिसे PostgreSQL, MySQL, SQLite आदि की बोलियाँ अलग-अलग हद तक लागू करती हैं।
• SQL As Understood By SQLiteSQLiteSQLite द्वारा स्वीकृत SQL व्याकरण, स्टेटमेंट दर स्टेटमेंट, सिंटैक्स डायग्राम के साथ।
• RFC 5789: PATCH Method for HTTPIETF · 2010आंशिक अपडेट के लिए PATCH मेथड, जबकि PUT पूरे रिसोर्स को बदल देता है।