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

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

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

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

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

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

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

SQL Connect की मदद से, PostgreSQL डेटाबेस में बुनियादी म्यूटेशन किए जा सकते हैं:

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

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

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

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

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

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

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


movie_insert फ़ील्ड के साथ म्यूटेशन

The movie_insert फ़ील्ड, Movie टेबल में एक रिकॉर्ड बनाने के लिए म्यूटेशन दिखाता है.

एक मूवी बनाने के लिए, इस फ़ील्ड का इस्तेमाल करें.

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


movie_update फ़ील्ड के साथ म्यूटेशन

movie_update फ़ील्ड, Movie टेबल में एक रिकॉर्ड अपडेट करने के लिए म्यूटेशन दिखाता है.

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

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


movie_delete फ़ील्ड के साथ म्यूटेशन

movie_delete फ़ील्ड, Movie टेबल में एक रिकॉर्ड मिटाने के लिए म्यूटेशन दिखाता है.

की की मदद से एक मूवी मिटाने के लिए, इस फ़ील्ड का इस्तेमाल करें.

  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
  • Int, Int64, Float, Date, और Timestamp डेटा टाइप को घटाने के लिए, dec

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

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

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

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

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

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

# 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 डायरेक्टिव. इसकी मदद से, सीईएल एक्सप्रेशन का इस्तेमाल करके, पढ़ने के लिए मौजूद कॉन्टेंट का आकलन किया जा सकता है. साथ ही, इस आकलन के नतीजों के आधार पर:

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

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

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

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

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

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

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

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

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

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

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

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

@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 जैसे कुछ म्यूटेशन फ़ील्ड, अगर तय की गई कुंजी वाला कोई रिकॉर्ड मौजूद नहीं है, तो कोई कार्रवाई नहीं कर सकते. इसी तरह, लुकअप में null या खाली सूची दिख सकती है. इन्हें गड़बड़ियां नहीं माना जाता. इसलिए, ये रोलबैक को ट्रिगर नहीं करेंगी.

इस नतीजे से बचने के लिए, यह जांचें कि @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")
}
@check

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

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

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

हालांकि, SQL Connect की मदद से, इस सामान्य स्थिति को एक ही कई चरणों वाली कार्रवाई में मैनेज किया जा सकता है. इसके लिए, दूसरे _insert में पहले _insert के नतीजों को ऐक्101सेस किया जाता है.

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

सर्वर वैल्यू के साथ फ़ील्ड सेट करने के लिए, 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 बाइंडिंग के बारे में ज़्यादा जानकारी के लिए, सीईएल रेफ़रंस देखें.

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

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

  • डेटाबेस की कार्रवाइयां विफल हो सकती हैं.
  • query @check लॉजिक, कार्रवाइयों को रोक सकता है.

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

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

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

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

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

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

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

अगले चरण

आपकी इसमें रुचि हो सकती है: