SQL Connect म्यूटेशन लागू करना

Firebase SQL Connect की मदद से, Cloud SQL से मैनेज किए जा रहे PostgreSQL इंस्टेंस के लिए कनेक्टर बनाए जा सकते हैं. ये कनेक्टर, आपके स्कीमा से डेटा इस्तेमाल करने के लिए क्वेरी और म्यूटेशन के कॉम्बिनेशन होते हैं.

शुरू करने से जुड़ी गाइड में, PostgreSQL के लिए फ़िल्म की समीक्षा करने वाले ऐप्लिकेशन के स्कीमा के बारे में बताया गया है.

उस गाइड में, डिप्लॉय की जा सकने वाली और ऐड हॉक एडमिन कार्रवाइयों के बारे में भी बताया गया था. इनमें म्यूटेशन भी शामिल हैं.

• डिप्लॉय किए जा सकने वाले म्यूटेशन वे होते हैं जिन्हें कनेक्टर में क्लाइंट ऐप्लिकेशन से कॉल करने के लिए लागू किया जाता है. इनमें आपके तय किए गए एपीआई एंडपॉइंट होते हैं. SQL Connect इन म्यूटेशन में पुष्टि करने और अनुमति देने की सुविधा को इंटिग्रेट करता है. साथ ही, आपके एपीआई के आधार पर क्लाइंट एसडीके टूल जनरेट करता है.
• एडमिन से जुड़े ऐड-हॉक म्यूटेशन, खास अधिकारों वाले एनवायरमेंट से चलाए जाते हैं, ताकि टेबल में डेटा भरा जा सके और उन्हें मैनेज किया जा सके. इन्हें Firebase कंसोल में बनाया और लागू किया जा सकता है. साथ ही, इन्हें Firebase Admin SDK का इस्तेमाल करके, खास अधिकारों वाले एनवायरमेंट में भी बनाया और लागू किया जा सकता है. इसके अलावा, इन्हें हमारे SQL Connect VS Code एक्सटेंशन का इस्तेमाल करके, लोकल डेवलपमेंट एनवायरमेंट में भी बनाया और लागू किया जा सकता है.

इस गाइड में, लागू किए जा सकने वाले म्यूटेशन के बारे में ज़्यादा जानकारी दी गई है.

SQL Connect म्यूटेशन की सुविधाएं

SQL Connect की मदद से, PostgreSQL डेटाबेस में बुनियादी बदलाव किए जा सकते हैं. इसके लिए, ये तरीके अपनाए जा सकते हैं:

• CRUD कार्रवाइयां करना
• लेन-देन की मदद से, कई चरणों वाली कार्रवाइयां मैनेज करना

हालांकि, SQL Connect के GraphQL एक्सटेंशन की मदद से, ज़्यादा तेज़ और असरदार ऐप्लिकेशन के लिए, बेहतर म्यूटेशन लागू किए जा सकते हैं:

• रिकॉर्ड पर बार-बार की जाने वाली कार्रवाइयों को आसान बनाने के लिए, कई कार्रवाइयों से मिले मुख्य स्केलर का इस्तेमाल करें
• सर्वर की ओर से उपलब्ध कराई गई कार्रवाइयों के साथ डेटा भरने के लिए, सर्वर वैल्यू का इस्तेमाल करना
• डेटा देखने के लिए, कई चरणों वाली म्यूटेशन कार्रवाइयों के दौरान क्वेरी करें. इससे कोड की लाइनों और सर्वर पर राउंड ट्रिप को सेव किया जा सकता है.

म्यूटेशन लागू करने के लिए, जनरेट किए गए फ़ील्ड का इस्तेमाल करना

SQL Connect की कार्रवाइयों से, फ़ील्ड का एक सेट अपने-आप बढ़ जाएगा. यह सेट, SQL Connect ने आपके स्कीमा में मौजूद टाइप और टाइप के संबंधों के आधार पर जनरेट किया है. जब भी स्कीमा में बदलाव किया जाता है, तब इन फ़ील्ड को स्थानीय टूलिंग से जनरेट किया जाता है.

मान लें कि आपके स्कीमा में Movie टाइप और उससे जुड़ा Actor टाइप मौजूद है. SQL Connect, movie_insert, movie_update, movie_delete फ़ील्ड और अन्य फ़ील्ड जनरेट करता है.

mutation CreateMovie($title: String!, $releaseYear: Int!, $genre: String!, $rating: Int!) {
  movie_insert(data: {
    title: $title
    releaseYear: $releaseYear
    genre: $genre
    rating: $rating
  })
}

mutation UpdateMovie($myKey: Movie_Key!, $genre: String, $rating: Int, $description: String) {
  movie_update(key: $myKey, data: {
    genre: $genre
    rating: $rating
    description: $description
  })
}

  mutation DeleteMovie($myKey: Movie_Key!) {
    movie_delete(key: $myKey) { key }
  }

म्यूटेशन के ज़रूरी एलिमेंट

SQL Connect म्यूटेशन, SQL Connect एक्सटेंशन वाले GraphQL म्यूटेशन होते हैं. सामान्य GraphQL म्यूटेशन की तरह ही, ऑपरेशन का नाम और GraphQL वैरिएबल की सूची तय की जा सकती है.

SQL Connect, GraphQL क्वेरी को ज़रूरत के मुताबिक बनाए गए निर्देशों के साथ बढ़ाता है. जैसे, @auth और @transaction.

इसलिए, इस म्यूटेशन में ये शामिल हैं:

• mutation टाइप की डेफ़िनिशन
• SignUp ऑपरेशन (म्यूटेशन) का नाम
• एकल वैरिएबल $username ऑपरेशन आर्ग्युमेंट
• एक डायरेक्टिव, @auth
• एक फ़ील्ड user_insert.

mutation SignUp($username: String!) @auth(level: USER) {
  user_insert(data: {
    id_expr: "auth.uid"
    username: $username
  })
}

हर म्यूटेशन आर्ग्युमेंट के लिए, टाइप का एलान करना ज़रूरी है. यह एलान, String जैसे बिल्ट-इन टाइप या Movie जैसे स्कीमा में तय किए गए कस्टम टाइप के ज़रिए किया जा सकता है.

बेसिक म्यूटेशन लिखना

अपने डेटाबेस से अलग-अलग रिकॉर्ड बनाने, अपडेट करने, और मिटाने के लिए, म्यूटेशन लिखना शुरू किया जा सकता है.

बनाएं

आइए, बुनियादी क्रिएटिव बनाते हैं.

# Create a movie based on user input
mutation CreateMovie($title: String!, $releaseYear: Int!, $genre: String!, $rating: Int!) {
  movie_insert(data: {
    title: $title
    releaseYear: $releaseYear
    genre: $genre
    rating: $rating
  })
}

# Create a movie with default values
mutation CreateMovie2 {
  movie_insert(data: {
    title: "Sherlock Holmes"
    releaseYear: 2009
    genre: "Mystery"
    rating: 5
  })
}

या अपसर्ट.

# Movie upsert using combination of variables and literals
mutation UpsertMovie($title: String!) {
  movie_upsert(data: {
    title: $title
    releaseYear: 2009
    genre: "Mystery"
    rating: 5
    genre: "Mystery/Thriller"
  })
}

अपडेट करना

यहां अपडेट दिए गए हैं. प्रोड्यूसर और डायरेक्टर को उम्मीद होती है कि औसत रेटिंग का यह ट्रेंड बना रहे.

movie_update फ़ील्ड में, रिकॉर्ड की पहचान करने के लिए id आर्ग्युमेंट होता है. साथ ही, इसमें data फ़ील्ड होता है. इसका इस्तेमाल इस अपडेट में वैल्यू सेट करने के लिए किया जा सकता है.

mutation UpdateMovie(
  $id: UUID!,
  $genre: String!,
  $rating: Int!,
  $description: String!
) {
  movie_update(id: $id,
    data: {
      genre: $genre
      rating: $rating
      description: $description
    })
}

एक से ज़्यादा अपडेट करने के लिए, movie_updateMany फ़ील्ड का इस्तेमाल करें.

# Multiple updates (increase all ratings of a genre)
mutation IncreaseRatingForGenre($genre: String!, $rating: Int!) {
  movie_updateMany(
    where: { genre: { eq: $genre } },
    data:
      {
        rating: $rating
      })
}

_update के साथ, इंक्रीमेंट, डिक्रीमेंट, अपेंड, और प्रीपेंड कार्रवाइयों का इस्तेमाल करना

_update और _updateMany म्यूटेशन में, data: में वैल्यू साफ़ तौर पर सेट की जा सकती हैं. हालांकि, वैल्यू अपडेट करने के लिए, अक्सर इंक्रीमेंट जैसे ऑपरेटर को लागू करना ज़्यादा सही होता है.

अपडेट के पिछले उदाहरण में बदलाव करने के लिए, मान लें कि आपको किसी फ़िल्म की रेटिंग बढ़ानी है. inc ऑपरेटर के साथ rating_update सिंटैक्स का इस्तेमाल किया जा सकता है.

mutation UpdateMovie(
  $id: UUID!,
  $ratingIncrement: Int!
) {
  movie_update(id: $id, data: {
    rating_update: {
      inc: $ratingIncrement
    }
  })
}

SQL Connect, फ़ील्ड अपडेट करने के लिए इन ऑपरेटर का इस्तेमाल करता है:

• Int, Int64, Float, Date, और Timestamp डेटा टाइप को बढ़ाने के लिए inc का इस्तेमाल करें
• dec का इस्तेमाल करके Int, Int64, Float, Date, और Timestamp डेटा टाइप की वैल्यू कम की जा सकती हैं

सूचियों के लिए, अलग-अलग वैल्यू या वैल्यू की सूचियों को अपडेट करने के लिए, इनका इस्तेमाल किया जा सकता है:

• add का इस्तेमाल करके, आइटम जोड़े जा सकते हैं. हालांकि, ऐसा सिर्फ़ तब किया जा सकता है, जब वे आइटम सूची के टाइप में पहले से मौजूद न हों. वेक्टर लिस्ट को छोड़कर, अन्य सभी लिस्ट के लिए ऐसा किया जा सकता है
• remove का इस्तेमाल, वेक्टर लिस्ट को छोड़कर, लिस्ट टाइप से सभी आइटम हटाने के लिए किया जाता है
• append का इस्तेमाल, वेक्टर लिस्ट को छोड़कर अन्य सभी तरह की लिस्ट में आइटम जोड़ने के लिए किया जाता है
• prepend का इस्तेमाल, वेक्टर लिस्ट को छोड़कर अन्य लिस्ट टाइप में आइटम जोड़ने के लिए किया जाता है

मिटाने की कार्रवाइयां करें

आपके पास, मूवी का डेटा मिटाने का विकल्प होता है. फ़िल्मों को सुरक्षित रखने वाले लोग, फ़िल्मों के फ़िज़िकल वर्शन को लंबे समय तक सुरक्षित रखना चाहेंगे.

# Delete by key
mutation DeleteMovie($id: UUID!) {
  movie_delete(id: $id)
}

यहां _deleteMany का इस्तेमाल किया जा सकता है.

# Multiple deletes
mutation DeleteUnpopularMovies($minRating: Int!) {
  movie_deleteMany(where: { rating: { le: $minRating } })
}

रिलेशन में म्यूटेशन लिखना

किसी संबंध पर, इंप्लिसिट _upsert म्यूटेशन का इस्तेमाल करने का तरीका देखें.

# Create or update a one to one relation
mutation MovieMetadataUpsert($movieId: UUID!, $director: String!) {
  movieMetadata_upsert(
    data: { movie: { id: $movieId }, director: $director }
  )
}

तेज़ी से बदलाव करने के लिए स्कीमा डिज़ाइन करना

SQL Connect दो अहम सुविधाएं उपलब्ध कराता है. इनकी मदद से, आपको ये काम करने में मदद मिलती है: बेहतर म्यूटेशन लिखना और राउंड-ट्रिप ऑपरेशन सेव करना.

मुख्य स्केलर, ऑब्जेक्ट आइडेंटिफ़ायर होते हैं. ये SQL Connect आपके स्कीमा के मुख्य फ़ील्ड से अपने-आप इकट्ठा होते हैं. मुख्य स्केलर, डेटा को ज़्यादा असरदार तरीके से प्रोसेस करने के बारे में होते हैं. इनकी मदद से, एक ही कॉल में अपने डेटा की पहचान और स्ट्रक्चर के बारे में जानकारी पाई जा सकती है. ये खास तौर पर तब काम आते हैं, जब आपको नए रिकॉर्ड पर क्रम से कार्रवाइयां करनी हों और आने वाले समय में होने वाले ऑपरेशनों के लिए, आपको एक यूनीक आइडेंटिफ़ायर की ज़रूरत हो. साथ ही, जब आपको ज़्यादा जटिल कार्रवाइयां करने के लिए, रिलेशनल कुंजियों को ऐक्सेस करना हो.

सर्वर वैल्यू का इस्तेमाल करके, सर्वर को अपनी टेबल में फ़ील्ड को डाइनैमिक तौर पर भरने की अनुमति दी जा सकती है. इसके लिए, सर्वर में सेव की गई वैल्यू या तुरंत कैलकुलेट की जा सकने वाली वैल्यू का इस्तेमाल किया जाता है. ये वैल्यू, expr आर्ग्युमेंट में मौजूद सर्वर-साइड CEL एक्सप्रेशन के हिसाब से होती हैं. उदाहरण के लिए, किसी फ़ील्ड को ऐसे टाइमस्टैंप के साथ तय किया जा सकता है जो फ़ील्ड को ऐक्सेस करते समय लागू होता है. इसके लिए, ऑपरेशन के अनुरोध में सेव किए गए समय updatedAt: Timestamp! @default(expr: "request.time") का इस्तेमाल किया जाता है.

ऐडवांस म्यूटेशन लिखना: SQL Connect को field_expr सिंटैक्स का इस्तेमाल करके वैल्यू देने की अनुमति देना

मुख्य स्केलर और सर्वर वैल्यू में बताए गए तरीके से, अपने स्कीमा को डिज़ाइन किया जा सकता है. इससे सर्वर, क्लाइंट के अनुरोधों के जवाब में id और तारीखों जैसे सामान्य फ़ील्ड की वैल्यू भर सकता है.

इसके अलावा, क्लाइंट ऐप्लिकेशन से SQL Connect request ऑब्जेक्ट में भेजे गए डेटा का इस्तेमाल किया जा सकता है. जैसे, यूज़र आईडी.

म्यूटेशन लागू करते समय, सर्वर से जनरेट किए गए अपडेट को ट्रिगर करने या अनुरोधों से डेटा ऐक्सेस करने के लिए, field_expr सिंटैक्स का इस्तेमाल करें. उदाहरण के लिए, _upsert ऑपरेशन के अनुरोध में सेव किए गए अनुमति uid को पास करने के लिए, userId_expr फ़ील्ड में "auth.uid" पास करें.

# Add a movie to the user's favorites list
mutation AddFavoritedMovie($movieId: UUID!) @auth(level: USER) {
  favorite_movie_upsert(data: { userId_expr: "auth.uid", movieId: $movieId })
}

# Remove a movie from the user's favorites list
mutation DeleteFavoritedMovie($movieId: UUID!) @auth(level: USER) {
  favorite_movie_delete(key: { userId_expr: "auth.uid", movieId: $movieId })
}

इसके अलावा, टास्क की सूची बनाने वाले किसी ऐप्लिकेशन में, नई सूची बनाते समय id_expr पास किया जा सकता है. इससे सर्वर को सूची के लिए यूयूआईडी अपने-आप जनरेट करने का निर्देश मिलेगा.

mutation CreateTodoListWithFirstItem(
  $listName: String!
) @transaction {
  # Step 1
  todoList_insert(data: {
    id_expr: "uuidV4()", # <-- auto-generated. Or a column-level @default on `type TodoList` will also work
    name: $listName,
  })
}

ज़्यादा जानकारी के लिए, स्केलर रेफ़रंस में _Expr स्केलर देखें.

एडवांस म्यूटेशन लिखना: एक से ज़्यादा चरणों वाली कार्रवाइयां

कई बार ऐसा हो सकता है, जब आपको एक ही म्यूटेशन में कई राइट फ़ील्ड (जैसे कि इंसर्ट) शामिल करने हों. आपको म्यूटेशन के दौरान अपने डेटाबेस को भी पढ़ना पड़ सकता है, ताकि मौजूदा डेटा को खोजा और उसकी पुष्टि की जा सके. ऐसा, उदाहरण के लिए, डेटा डालने या अपडेट करने से पहले किया जाता है. इन विकल्पों से, दोतरफ़ा यात्रा के ऑपरेशन और लागत कम हो जाती है.

SQL Connect की मदद से, म्यूटेशन में कई चरणों वाला लॉजिक इस्तेमाल किया जा सकता है. इसके लिए, ये काम किए जा सकते हैं:

• एक से ज़्यादा राइट फ़ील्ड

• आपके म्यूटेशन में एक से ज़्यादा रीड फ़ील्ड (query फ़ील्ड कीवर्ड का इस्तेमाल करके).

• @transaction डायरेक्टिव, जो रिलेशनल डेटाबेस से ट्रांज़ैक्शन सपोर्ट उपलब्ध कराता है.

• @check डायरेक्टिव, जिसकी मदद से CEL एक्सप्रेशन का इस्तेमाल करके, पढ़े गए कॉन्टेंट का आकलन किया जा सकता है. साथ ही, इस आकलन के नतीजों के आधार पर:

  • म्यूटेशन के ज़रिए तय किए गए बदलावों को लागू करना
  • क्वेरी फ़ील्ड के नतीजे दिखाने के लिए आगे बढ़ें
  • क्लाइंट कोड में सही लॉजिक लागू करने के लिए, वापस भेजे गए मैसेज का इस्तेमाल करना

• @redact डायरेक्टिव, जिसकी मदद से क्वेरी फ़ील्ड के नतीजों को वायर प्रोटोकॉल के नतीजों से हटाया जा सकता है.

• CEL response बाइंडिंग, जो कई चरणों वाली मुश्किल प्रोसेस में किए गए सभी बदलावों और क्वेरी के नतीजों को सेव करती है. response बाइंडिंग को ऐक्सेस किया जा सकता है:

  • @check डायरेक्टिव में, expr: आर्ग्युमेंट के ज़रिए
  • सर्वर वैल्यू के साथ, field_expr सिंटैक्स का इस्तेमाल करना

@transaction डायरेक्टिव

एक से ज़्यादा चरणों वाले म्यूटेशन के लिए, लेन-देन का इस्तेमाल करके गड़बड़ी को ठीक करने की सुविधा उपलब्ध है.

@transaction डायरेक्टिव यह पक्का करता है कि बदलाव, डेटाबेस ट्रांज़ैक्शन में हमेशा चले. भले ही, बदलाव में एक राइट फ़ील्ड (उदाहरण के लिए, _insert या _update) या एक से ज़्यादा राइट फ़ील्ड शामिल हों.

• @transaction के बिना म्यूटेशन, हर रूट फ़ील्ड को एक के बाद एक क्रम से लागू करते हैं. इस ऑपरेशन से, फ़ील्ड में मौजूद कुछ गड़बड़ियां दिखती हैं. हालांकि, बाद में होने वाले बदलावों का असर नहीं दिखता.

• @transaction वाले म्यूटेशन के लिए, यह गारंटी दी जाती है कि वे या तो पूरी तरह से सफल होंगे या पूरी तरह से फ़ेल होंगे. अगर लेन-देन के दौरान किसी भी फ़ील्ड में गड़बड़ी होती है, तो पूरा लेन-देन वापस कर दिया जाता है.

@check और @redact डायरेक्टिव

@check डायरेक्टिव यह पुष्टि करता है कि क्वेरी के नतीजों में बताए गए फ़ील्ड मौजूद हैं. फ़ील्ड की वैल्यू की जांच करने के लिए, कॉमन एक्सप्रेशन लैंग्वेज (सीईएल) एक्सप्रेशन का इस्तेमाल किया जाता है. इस डायरेक्टिव का डिफ़ॉल्ट व्यवहार यह है कि यह उन नोड की जांच करता है जिनकी वैल्यू null या [] (खाली सूचियां) है और उन्हें अस्वीकार कर देता है.

@redact डायरेक्टिव, क्लाइंट के जवाब के कुछ हिस्से को छिपा देता है. बदलाव किए गए फ़ील्ड का आकलन अब भी साइड इफ़ेक्ट (इसमें डेटा में बदलाव और @check शामिल हैं) के लिए किया जाता है. साथ ही, नतीजे अब भी CEL एक्सप्रेशन के बाद के चरणों में उपलब्ध होते हैं.

@check, @check(message:), और @redact का इस्तेमाल करना

@check और @redact का मुख्य इस्तेमाल, मिलते-जुलते डेटा को ढूंढना है. इससे यह तय किया जा सकता है कि कुछ कार्रवाइयों को अनुमति दी जानी चाहिए या नहीं. इसके लिए, लॉजिक में लुकअप का इस्तेमाल किया जाता है, लेकिन इसे क्लाइंट से छिपाया जाता है. आपकी क्वेरी, क्लाइंट कोड में सही तरीके से हैंडल करने के लिए काम के मैसेज दिखा सकती है.

query GetMovieEditors($movieId: UUID!) @auth(level: USER) {
  moviePermission(key: { movieId: $movieId, userId_expr: "auth.uid" }) @redact {
    role @check(expr: "this == 'admin'", message: "You must be an admin to view all editors of a movie.")
  }
  moviePermissions(where: { movieId: { eq: $movieId }, role: { eq: "editor" } }) {
    user {
      id
      username
    }
  }
}

अनुमति की जांच में @check और @redact डायरेक्टिव के बारे में ज़्यादा जानने के लिए, अनुमति से जुड़े डेटा को खोजने के बारे में चर्चा पढ़ें.

कुंजियों की पुष्टि करने के लिए, @check का इस्तेमाल करना

_update जैसे कुछ म्यूटेशन फ़ील्ड, अगर तय की गई कुंजी वाला रिकॉर्ड मौजूद नहीं है, तो कोई कार्रवाई नहीं करेंगे. इसी तरह, लुकअप से शून्य या खाली सूची मिल सकती है. इन्हें गड़बड़ियां नहीं माना जाता. इसलिए, इनसे रोलबैक ट्रिगर नहीं होंगे.

इस नतीजे से बचने के लिए, जांच करें कि @check डायरेक्टिव का इस्तेमाल करके कुंजियां ढूंढी जा सकती हैं या नहीं.

# Delete by key, error if not found
mutation MustDeleteMovie($id: UUID!) @transaction {
  movie_delete(id: $id) @check(expr: "this != null", message: "Movie not found, therefore nothing is deleted")
}

एक से ज़्यादा चरणों वाले म्यूटेशन को चेन करने के लिए, response बाइंडिंग का इस्तेमाल करें

मिलते-जुलते रिकॉर्ड बनाने का बुनियादी तरीका यह है. उदाहरण के लिए, एक नया Movie और उससे जुड़ी MovieMetadata एंट्री बनाने के लिए:

1. Movie के लिए _insert म्यूटेशन को कॉल करना
2. बनाई गई मूवी की वापस की गई कुंजी को सेव करता है
3. इसके बाद, MovieMetadata रिकॉर्ड बनाने के लिए, दूसरे _insert म्यूटेशन को कॉल करें.

हालांकि, SQL Connect की मदद से, इस सामान्य समस्या को एक ही बार में हल किया जा सकता है. इसके लिए, आपको पहले _insert के नतीजों को दूसरे _insert में ऐक्सेस करना होगा.

फ़िल्म की समीक्षा करने वाला एक सफल ऐप्लिकेशन बनाना बहुत मुश्किल काम है. आइए, एक नए उदाहरण की मदद से, अपनी 'करने के लिए काम' सूची को ट्रैक करें.

सर्वर वैल्यू वाले फ़ील्ड सेट करने के लिए, response का इस्तेमाल करना

काम की सूची में किए गए इस बदलाव में:

• response बाइंडिंग, अब तक के अधूरे जवाब वाले ऑब्जेक्ट को दिखाती है. इसमें मौजूदा फ़ील्ड से पहले के सभी टॉप-लेवल म्यूटेशन फ़ील्ड शामिल होते हैं.
• todoList_insert ऑपरेशन के नतीजों को बाद में response.todoList_insert.id में ऐक्सेस किया जाता है. इस ऑपरेशन से id (कुंजी) फ़ील्ड मिलता है. ऐसा इसलिए किया जाता है, ताकि हम तुरंत कोई नया काम जोड़ सकें.

mutation CreateTodoListWithFirstItem(
  $listName: String!,
  $itemContent: String!
) @transaction {
  # Sub-step 1:
  todoList_insert(data: {
    id_expr: "uuidV4()", # <-- auto-generated. Or a column-level @default on `type TodoList` will also work
    name: $listName,
  })
  # Sub-step 2:
  todo_insert(data: {
    listId_expr: "response.todoList_insert.id" # <-- Grab the newly generated ID from the partial response so far.
    content: $itemContent,
  })
}

@check का इस्तेमाल करके फ़ील्ड की पुष्टि करने के लिए, response का इस्तेमाल करना

response, @check(expr: "...") में भी उपलब्ध है. इसलिए, इसका इस्तेमाल सर्वर-साइड के ज़्यादा मुश्किल लॉजिक बनाने के लिए किया जा सकता है. म्यूटेशन में query { … } चरणों के साथ मिलकर काम करने पर, आपको क्लाइंट-सर्वर के बीच होने वाले अतिरिक्त राउंडट्रिप के बिना ही ज़्यादा फ़ायदे मिल सकते हैं.

यहां दिए गए उदाहरण में ध्यान दें कि @check के पास पहले से ही response.query का ऐक्सेस है, क्योंकि @check हमेशा उस चरण के बाद चलता है जिससे इसे अटैच किया गया है.

mutation CreateTodoInNamedList(
  $listName: String!,
  $itemContent: String!
) @transaction {
  # Sub-step 1: Look up List.id by its name
  query
  @check(expr: "response.query.todoLists.size() > 0", message: "No such TodoList with the name!")
  @check(expr: "response.query.todoLists.size() < 2", message: "Ambiguous listName!") {
    todoLists(where: { name: $listName }) {
      id
    }
  }
  # Sub-step 2:
  todo_insert(data: {
    listId_expr: "response.todoLists[0].id" # <-- Now we have the parent list ID to insert to
    content: $itemContent,
  })
}

response बाइंडिंग के बारे में ज़्यादा जानने के लिए, CEL रेफ़रंस देखें.

@transaction और query @check की मदद से, रोकी गई कार्रवाइयों के बारे में जानकारी

एक से ज़्यादा चरणों वाले म्यूटेशन में गड़बड़ियां हो सकती हैं:

• डेटाबेस से जुड़ी कार्रवाइयां पूरी नहीं हो सकती हैं.
• क्वेरी @check लॉजिक, कार्रवाइयों को बंद कर सकता है.

SQL Connect का सुझाव है कि आप कई चरणों वाले म्यूटेशन के साथ @transaction डायरेक्टिव का इस्तेमाल करें. इससे, डेटाबेस ज़्यादा एक जैसा होता है. साथ ही, म्यूटेशन के ऐसे नतीजे मिलते हैं जिन्हें क्लाइंट कोड में आसानी से मैनेज किया जा सकता है:

• पहली गड़बड़ी होने या @check की स्थिति में, कार्रवाई बंद हो जाएगी. इसलिए, बाद के किसी भी फ़ील्ड के एक्ज़ीक्यूशन या सीएलईएल के आकलन को मैनेज करने की ज़रूरत नहीं है.
• डेटाबेस में गड़बड़ियों या @check लॉजिक की वजह से रोलबैक किए जाते हैं. इससे डेटाबेस की स्थिति एक जैसी बनी रहती है.
• रोलबैक की गड़बड़ी हमेशा क्लाइंट कोड को भेजी जाती है.

इस्तेमाल के कुछ ऐसे उदाहरण हो सकते हैं जिनमें आपको @transaction का इस्तेमाल नहीं करना हो: उदाहरण के लिए, अगर आपको ज़्यादा थ्रूपुट, स्केलेबिलिटी या उपलब्धता की ज़रूरत है, तो हो सकता है कि आप इवेंचुअल कंसिस्टेंसी का विकल्प चुनें. हालांकि, नतीजे पाने के लिए आपको अपने डेटाबेस और क्लाइंट कोड को मैनेज करना होगा:

• अगर डेटाबेस ऑपरेशन की वजह से कोई फ़ील्ड काम नहीं करता है, तो इसके बाद वाले फ़ील्ड काम करते रहेंगे. हालांकि, फ़ेल हुए @checks से पूरी कार्रवाई बंद हो जाती है.
• रोलबैक नहीं किए जाते. इसका मतलब है कि डेटाबेस की स्थिति में बदलाव नहीं किया जाता. हालांकि, कुछ अपडेट लागू हो जाते हैं और कुछ अपडेट लागू नहीं होते.
• अगर @check के लॉजिक में, पिछले चरण में पढ़े गए और/या लिखे गए नतीजों का इस्तेमाल किया जाता है, तो @check के साथ किए गए आपके ऑपरेशन से ज़्यादा अलग-अलग नतीजे मिल सकते हैं.
• क्लाइंट कोड को मिले नतीजे में, सफलता और गड़बड़ी वाले ज़्यादा जटिल जवाब शामिल होंगे.

SQL Connect म्यूटेशन के लिए डायरेक्टिव

टाइप और टेबल तय करने के लिए इस्तेमाल किए जाने वाले डायरेक्टिव के अलावा, SQL Connect, @auth, @check, @redact, और @transaction डायरेक्टिव भी उपलब्ध कराता है. इनका इस्तेमाल करके, कार्रवाइयों के व्यवहार को बेहतर बनाया जा सकता है.

अगले चरण

आपकी इनमें दिलचस्पी हो सकती है:

• एआई की मदद से काम करने वाले टूल का इस्तेमाल करके, अपने ऐप्लिकेशन के लिए म्यूटेशन जनरेट करना
• अनुमति से जुड़ी गाइड के मुताबिक, म्यूटेशन को अनुमति देना
• वेब, iOS, Android, और Flutter के लिए, क्लाइंट कोड से म्यूटेशन कॉल करना.
• म्यूटेशन की मदद से, डेटा से जुड़े कई ऑपरेशन एक साथ करना