Data Connect के स्कीमा, क्वेरी, और म्यूटेशन

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

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

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

इस गाइड में, स्कीमा के उदाहरणों के साथ Data Connect क्वेरी और म्यूटेशन को जोड़ा गया है. Data Connect स्कीमा के बारे में बताने वाली गाइड में, क्वेरी (और म्यूटेशन) के बारे में क्यों चर्चा की गई है? GraphQL पर आधारित अन्य प्लैटफ़ॉर्म की तरह ही, Firebase Data Connect भी क्वेरी-फ़र्स्ट डेवलपमेंट प्लैटफ़ॉर्म है. इसलिए, डेवलपर के तौर पर, आपको डेटा मॉडलिंग में अपने क्लाइंट के ज़रूरी डेटा के बारे में सोचना होगा. इससे, आपके प्रोजेक्ट के लिए डेटा स्कीमा पर काफ़ी असर पड़ेगा.

इस गाइड में, फ़िल्म की समीक्षाओं के लिए नए स्कीमा के बारे में बताया गया है. इसके बाद, उस स्कीमा से मिली क्वेरी और म्यूटेशन के बारे में बताया गया है. आखिर में, मुख्य Data Connect स्कीमा के बराबर की एसक्यूएल लिस्टिंग दी गई है.

फ़िल्म की समीक्षा करने वाले ऐप्लिकेशन के लिए स्कीमा

मान लें कि आपको ऐसी सेवा बनानी है जिससे उपयोगकर्ता, फ़िल्मों की समीक्षाएं सबमिट और देख सकें.

ऐसे ऐप्लिकेशन के लिए, आपको शुरुआती स्कीमा की ज़रूरत होगी. जटिल रिलेशनल क्वेरी बनाने के लिए, आपको बाद में इस स्कीमा को बड़ा करना होगा.

मूवी टेबल

फ़िल्मों के स्कीमा में मुख्य निर्देश शामिल होते हैं, जैसे:

• @table(name) और @col(name), ताकि SQL टेबल और कॉलम के नामों को पसंद के मुताबिक बनाया जा सके. अगर नाम नहीं दिया जाता है, तो Data Connect, snake_case नाम जनरेट करता है.
• @col(dataType) का इस्तेमाल करके, एसक्यूएल कॉलम के टाइप को पसंद के मुताबिक बनाएं.
• @default, जोड़ने के दौरान SQL कॉलम की डिफ़ॉल्ट वैल्यू कॉन्फ़िगर करने के लिए.

ज़्यादा जानकारी के लिए, @table, @col, @default के रेफ़रंस दस्तावेज़ देखें.

# Movies
type Movie @table(name: "movie", key: "id") {
  id: UUID! @col(name: "movie_id") @default(expr: "uuidV4()")
  title: String!
  releaseYear: Int
  genre: String @col(dataType: "varchar(20)")
  rating: Int
  description: String
}

मुख्य स्केलर और सर्वर वैल्यू

फ़िल्म की समीक्षा करने वाले ऐप्लिकेशन के बारे में ज़्यादा जानने से पहले, Data Connect कीवर्ड स्केलर और सर्वर वैल्यू के बारे में बताते हैं.

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

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

मूवी का मेटाडेटा टेबल

अब फ़िल्म के निर्देशकों का ट्रैक रखते हैं. साथ ही, Movie के साथ एक-एक करके संबंध सेट अप करते हैं.

रिलेशनशिप तय करने के लिए, रेफ़रंस फ़ील्ड जोड़ें.

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

• @ref(fields) का इस्तेमाल करके, फ़ॉरेन की फ़ील्ड तय करें.
• @ref(references), ताकि टारगेट टेबल में रेफ़र किए गए फ़ील्ड की जानकारी दी जा सके. यह रेफ़रंस डिफ़ॉल्ट रूप से प्राइमरी कुंजी पर सेट होता है. हालांकि, @unique वाले फ़ील्ड का इस्तेमाल भी किया जा सकता है.

ज़्यादा जानकारी के लिए, @ref के रेफ़रंस दस्तावेज़ देखें.

# Movie Metadata
# Movie - MovieMetadata is a one-to-one relationship
type MovieMetadata @table {
  # @unique ensures that each Movie only has one MovieMetadata.
  movie: Movie! @unique
  # Since it references to another table type, it adds a foreign key constraint.
  #  movie: Movie! @unique @ref(fields: "movieId", references: "id")
  #  movieId: UUID! <- implicitly added foreign key field
  director: String
}

Actor और MovieActor

इसके बाद, आपको अपनी फ़िल्मों में कलाकारों को कास्ट करना है. फ़िल्मों और कलाकारों के बीच कई-से-कई संबंध होने की वजह से, जॉइन टेबल बनाएं.

# Actors
# Suppose an actor can participate in multiple movies and movies can have multiple actors
# Movie - Actors (or vice versa) is a many to many relationship
type Actor @table {
  id: UUID! @default(expr: "uuidV4()")
  name: String! @col(dataType: "varchar(30)")
}
# Join table for many-to-many relationship for movies and actors
# The 'key' param signifies the primary keys of this table
# In this case, the keys are [movieId, actorId], the foreign key fields of the reference fields [movie, actor]
type MovieActor @table(key: ["movie", "actor"]) {
  movie: Movie!
  # movieId: UUID! <- implicitly added foreign key field
  actor: Actor!
  # actorId: UUID! <- implicitly added foreign key field
  role: String! # "main" or "supporting"
  # optional other fields
}

उपयोगकर्ता

आखिर में, आपके ऐप्लिकेशन के उपयोगकर्ता.

# Users
# Suppose a user can leave reviews for movies
type User @table {
  id: String! @default(expr: "auth.uid")
  username: String! @col(dataType: "varchar(50)")
}

ऐसे डेटा टाइप जिन्हें PostgreSQL में प्रोसेस किया जा सकता है

Data Connect, स्केलर डेटा टाइप के साथ काम करता है. साथ ही, @col(dataType:) का इस्तेमाल करके PostgreSQL टाइप को असाइन करता है.

• GraphQL List, एक डाइमेंशन वाले ऐरे पर मैप होता है.
  • उदाहरण के लिए, [Int] को int5[] से मैप किया जाता है, [Any] को jsonb[] से मैप किया जाता है.
  • Data Connect में नेस्ट किए गए ऐरे का इस्तेमाल नहीं किया जा सकता.

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

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

• जैसा कि आपको 'शुरू करने के लिए गाइड' में पता चला है, Firebase console और हमारे स्थानीय डेवलपमेंट टूल, अपने-आप जनरेट होने वाले इन फ़ील्ड का इस्तेमाल करके, आपको एड-हॉक एडमिन क्वेरी और म्यूटेशन उपलब्ध कराते हैं. इनका इस्तेमाल, डेटा को सीड करने और अपनी टेबल के कॉन्टेंट की पुष्टि करने के लिए किया जा सकता है.

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

फ़ील्ड के लिए अपने-आप नाम तय होना

Data Connect, आपके स्कीमा टाइप के एलान के आधार पर, अपने-आप जनरेट होने वाले फ़ील्ड के लिए सही नामों का अनुमान लगाता है. उदाहरण के लिए, PostgreSQL के सोर्स का इस्तेमाल करते समय, अगर आपने Movie नाम की टेबल तय की है, तो सर्वर यह जनरेट करेगा:

• एक टेबल के इस्तेमाल के उदाहरणों में डेटा पढ़ने के लिए फ़ील्ड, movie (एकवचन, eq जैसे आर्ग्युमेंट पास करके अलग-अलग नतीजे पाने के लिए) और movies (बहुवचन, gt जैसे आर्ग्युमेंट और orderby जैसे ऑपरेशन पास करके नतीजों की सूचियां पाने के लिए) जैसे आसान नामों के साथ इस्तेमाल किए जाते हैं. Data Connect, actors_on_movies या actors_via_actormovie जैसे साफ़ तौर पर बताए गए नामों के साथ, कई टेबल और रिलेशनल ऑपरेशन के लिए भी फ़ील्ड जनरेट करता है.
• movie_insert, movie_upsert जैसे जाने-पहचाने नामों से डेटा लिखने के लिए फ़ील्ड...

स्कीमा डेफ़िनिशन लैंग्वेज की मदद से, यह भी साफ़ तौर पर कंट्रोल किया जा सकता है कि singular और plural डायरेक्टिव आर्ग्युमेंट का इस्तेमाल करके, फ़ील्ड के लिए नाम कैसे जनरेट किए जाएं.

क्वेरी और म्यूटेशन के लिए निर्देश

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

फ़िल्म की समीक्षा के डेटाबेस के लिए क्वेरी

Data Connect क्वेरी को क्वेरी ऑपरेशन टाइप के एलान, ऑपरेशन के नाम, शून्य या उससे ज़्यादा ऑपरेशन आर्ग्युमेंट, और आर्ग्युमेंट के साथ शून्य या उससे ज़्यादा निर्देशों के साथ तय किया जाता है.

क्विकस्टार्ट में, उदाहरण के तौर पर दी गई listEmails क्वेरी में कोई पैरामीटर नहीं था. हालांकि, कई मामलों में क्वेरी फ़ील्ड में भेजा गया डेटा डाइनैमिक होगा. क्वेरी डेफ़िनिशन के कॉम्पोनेंट के तौर पर वैरिएबल के साथ काम करने के लिए, $variableName सिंटैक्स का इस्तेमाल किया जा सकता है.

इसलिए, इस क्वेरी में:

• query टाइप की परिभाषा
• ListMoviesByGenre ऑपरेशन (क्वेरी) का नाम
• एक वैरिएबल $genre ऑपरेशन आर्ग्युमेंट
• एक डायरेक्टिव, @auth.

query ListMoviesByGenre($genre: String!) @auth(level: USER)

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

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

क्वेरी में मुख्य स्केलर

हालांकि, सबसे पहले मुख्य स्केलर के बारे में जानकारी दें.

Data Connect, मुख्य स्केलर के लिए एक खास टाइप तय करता है, जिसकी पहचान _Key से की जाती है. उदाहरण के लिए, हमारी Movie टेबल के लिए, मुख्य स्केलर का टाइप Movie_Key है.

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

हमारे मौजूदा उदाहरण में movie जैसी सिंगल ऑटोमैटिक क्वेरी, एक मुख्य आर्ग्युमेंट के साथ काम करती हैं. यह आर्ग्युमेंट, मुख्य स्केलर स्वीकार करता है.

किसी मुख्य स्केलर को लिटरल के तौर पर पास किया जा सकता है. हालांकि, इनपुट के तौर पर मुख्य स्केलर पास करने के लिए, वैरिएबल तय किए जा सकते हैं.

query GetMovie($myKey: Movie_Key!) {
  movie(key: $myKey) { title }
}

इन्हें अनुरोध के JSON फ़ॉर्मैट में इस तरह या सीरियलाइज़ेशन के अन्य फ़ॉर्मैट में दिया जा सकता है:

{
  # …
  "variables": {
    "myKey": {"foo": "some-string-value", "bar": 42}
  }
}

कस्टम स्केलर पार्सिंग की मदद से, ऑब्जेक्ट सिंटैक्स का इस्तेमाल करके भी Movie_Key बनाया जा सकता है. इसमें वैरिएबल हो सकते हैं. यह सुविधा तब ज़्यादा काम की होती है, जब आपको किसी वजह से अलग-अलग कॉम्पोनेंट को अलग-अलग वैरिएबल में बांटना हो.

क्वेरी में बदलाव करना

Data Connect क्वेरी में GraphQL के लिए, किसी एलिमेंट को किसी दूसरे नाम से दिखाने की सुविधा के साथ काम करता है. किसी क्वेरी के नतीजों में दिखने वाले डेटा का नाम बदलने के लिए, उपनाम का इस्तेमाल किया जाता है. एक Data Connect क्वेरी, सर्वर पर एक ही अनुरोध में कई फ़िल्टर या क्वेरी के अन्य ऑपरेशन लागू कर सकती है. साथ ही, एक साथ कई "सब-क्वेरी" जारी कर सकती है. दिखाए गए डेटा सेट में नामों के मेल खाने से बचने के लिए, सब-क्वेरी को अलग-अलग दिखाने के लिए, वैकल्पिक नामों का इस्तेमाल किया जाता है.

यहां एक क्वेरी दी गई है, जिसमें एक्सप्रेशन में mostPopular का इस्तेमाल किया गया है.

query ReviewTopPopularity($genre: String) {
  mostPopular: review(first: {
    where: {genre: {eq: $genre}},
    orderBy: {popularity: DESC}
  }) { … }
}

फ़िल्टर की मदद से आसान क्वेरी बनाना

Data Connect क्वेरी, सभी सामान्य SQL फ़िल्टर और ऑर्डर ऑपरेशन से मैप होती हैं.

where और orderBy ऑपरेटर (एकवचन, बहुवचन क्वेरी)

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

query MovieByTopRating($genre: String) {
  mostPopular: movies(
     where: { genre: { eq: $genre } }, orderBy: { rating: DESC }
  ) {
    # graphql: list the fields from the results to return
    id
    title
    genre
    description
  }
}

query MoviesByReleaseYear($min: Int, $max: Int) {
  movies(where: {releaseYear: {le: $max, ge: $min}}, orderBy: [{releaseYear: ASC}]) { … }
}

limit और offset ऑपरेटर (एकवचन, बहुवचन क्वेरी)

नतीजों को पेज के हिसाब से देखा जा सकता है. इन आर्ग्युमेंट को स्वीकार किया जाता है, लेकिन नतीजों में नहीं दिखाया जाता.

query MoviesTop10 {
  movies(orderBy: [{ rating: DESC }], limit: 10) {
    # graphql: list the fields from the results to return
    title
  }
}

ऐरे फ़ील्ड के लिए शामिल है

यह जांच की जा सकती है कि किसी ऐरे फ़ील्ड में कोई खास आइटम शामिल है या नहीं.

# Filter using arrays and embedded fields.
query ListMoviesByTag($tag: String!) {
  movies(where: { tags: { includes: $tag }}) {
    # graphql: list the fields from the results to return
    id
    title
  }
}

स्ट्रिंग ऑपरेशन और रेगुलर एक्सप्रेशन

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

query MoviesTitleSearch($prefix: String, $suffix: String, $contained: String, $regex: String) {
  prefixed: movies(where: {title: {startsWith: $prefix}}) {...}
  suffixed: movies(where: {title: {endsWith: $suffix}}) {...}
  contained: movies(where: {title: {contains: $contained}}) {...}
  matchRegex: movies(where: {title: {pattern: {regex: $regex}}}) {...}
}

कंपोज किए गए फ़िल्टर के लिए or और and

ज़्यादा जटिल लॉजिक के लिए, or और and का इस्तेमाल करें.

query ListMoviesByGenreAndGenre($minRating: Int!, $genre: String) {
  movies(
    where: { _or: [{ rating: { ge: $minRating } }, { genre: { eq: $genre } }] }
  ) {
    # graphql: list the fields from the results to return
    title
  }
}

Complex क्वेरी

Data Connect क्वेरी, टेबल के बीच के संबंधों के आधार पर डेटा ऐक्सेस कर सकती हैं. नेस्ट की गई क्वेरी बनाने के लिए, अपने स्कीमा में तय किए गए ऑब्जेक्ट (वन-टू-वन) या कलेक्शन (वन-टू-मेनी) रिलेशनशिप का इस्तेमाल किया जा सकता है. इसका मतलब है कि नेस्ट किए गए या मिलते-जुलते टाइप के डेटा के साथ-साथ, एक टाइप का डेटा भी फ़ेच किया जा सकता है.

ऐसी क्वेरी, जनरेट किए गए रीड फ़ील्ड में मैजिक Data Connect _on_ और _via सिंटैक्स का इस्तेमाल करती हैं.

आपको हमारे शुरुआती वर्शन के स्कीमा में बदलाव करने होंगे.

कई से एक

आइए, अपने ऐप्लिकेशन में समीक्षाएं जोड़ते हैं. इसके लिए, Review टेबल और User में बदलाव करें.

# User table is keyed by Firebase Auth UID.
type User @table {
  # `@default(expr: "auth.uid")` sets it to Firebase Auth UID during insert and upsert.
  id: String! @default(expr: "auth.uid")
  username: String! @col(dataType: "varchar(50)")
  # The `user: User!` field in the Review table generates the following one-to-many query field.
  #  reviews_on_user: [Review!]!
  # The `Review` join table the following many-to-many query field.
  #  movies_via_Review: [Movie!]!
}

# Reviews is a join table tween User and Movie.
# It has a composite primary keys `userUid` and `movieId`.
# A user can leave reviews for many movies. A movie can have reviews from many users.
# User  <-> Review is a one-to-many relationship
# Movie <-> Review is a one-to-many relationship
# Movie <-> User is a many-to-many relationship
type Review @table(name: "Reviews", key: ["movie", "user"]) {
  user: User!
  # The user field adds the following foreign key field. Feel free to uncomment and customize it.
  #  userUid: String!
  movie: Movie!
  # The movie field adds the following foreign key field. Feel free to uncomment and customize it.
  #  movieId: UUID!
  rating: Int
  reviewText: String
  reviewDate: Date! @default(expr: "request.time")
}

कई-एक के लिए क्वेरी

अब _via_ सिंटैक्स को समझने के लिए, किसी ऐसी क्वेरी पर नज़र डालें जिसमें अलग नाम दिया गया हो.

query UserMoviePreferences($username: String!) @auth(level: USER) {
  users(where: { username: { eq: $username } }) {
    likedMovies: movies_via_Review(where: { rating: { ge: 4 } }) {
      title
      genre
    }
    dislikedMovies: movies_via_Review(where: { rating: { le: 2 } }) {
      title
      genre
    }
  }
}

वन-टू-वन

आपको पैटर्न दिख सकता है. उदाहरण के लिए, नीचे स्कीमा में बदलाव किया गया है.

# Movies
type Movie
  @table(name: "Movies", singular: "movie", plural: "movies", key: ["id"]) {
  id: UUID! @col(name: "movie_id") @default(expr: "uuidV4()")
  title: String!
  releaseYear: Int @col(name: "release_year")
  genre: String
  rating: Int @col(name: "rating")
  description: String @col(name: "description")
  tags: [String] @col(name: "tags")
}
# Movie Metadata
# Movie - MovieMetadata is a one-to-one relationship
type MovieMetadata
  @table(
    name: "MovieMetadata"
  ) {
  # @ref creates a field in the current table (MovieMetadata) that holds the primary key of the referenced type
  # In this case, @ref(fields: "id") is implied
  movie: Movie! @ref
  # movieId: UUID <- this is created by the above @ref
  director: String @col(name: "director")
}


extend type MovieMetadata {
  movieId: UUID! # matches primary key of referenced type
...
}

extend type Movie {
  movieMetadata: MovieMetadata # can only be non-nullable on ref side
  # conflict-free name, always generated
  movieMetadatas_on_movie: MovieMetadata
}

एक-एक करके सवाल पूछने के लिए क्वेरी

_on_ सिंटैक्स का इस्तेमाल करके क्वेरी की जा सकती है.

# One to one
query GetMovieMetadata($id: UUID!) @auth(level: PUBLIC) {
  movie(id: $id) {
    movieMetadatas_on_movie {
      director
    }
  }
}

कई-से-कई

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

# MovieActors Join Table Definition
type MovieActors @table(
  key: ["movie", "actor"] # join key triggers many-to-many generation
) {
  movie: Movie!
  actor: Actor!
}

# generated extensions for the MovieActors join table
extend type MovieActors {
  movieId: UUID!
  actorId: UUID!
}

# Extensions for Actor and Movie to handle many-to-many relationships
extend type Movie {
  movieActors: [MovieActors!]! # standard many-to-one relation to join table
  actors: [Actor!]! # many-to-many via join table

  movieActors_on_actor: [MovieActors!]!
  # since MovieActors joins distinct types, type name alone is sufficiently precise
  actors_via_MovieActors: [Actor!]!
}

extend type Actor {
  movieActors: [MovieActors!]! # standard many-to-one relation to join table
  movies: [Movie!]! # many-to-many via join table

  movieActors_on_movie: [MovieActors!]!
  movies_via_MovieActors: [Movie!]!
}

कई-से-कई के लिए क्वेरी

_via_ सिंटैक्स को समझने के लिए, आइए किसी ऐसी क्वेरी पर नज़र डालें जिसमें अलग-अलग नाम दिए गए हैं.

query GetMovieCast($movieId: UUID!, $actorId: UUID!) @auth(level: PUBLIC) {
  movie(id: $movieId) {
    mainActors: actors_via_MovieActor(where: { role: { eq: "main" } }) {
      name
    }
    supportingActors: actors_via_MovieActor(
      where: { role: { eq: "supporting" } }
    ) {
      name
    }
  }
  actor(id: $actorId) {
    mainRoles: movies_via_MovieActor(where: { role: { eq: "main" } }) {
      title
    }
    supportingRoles: movies_via_MovieActor(
      where: { role: { eq: "supporting" } }
    ) {
      title
    }
  }
}

एग्रीगेशन क्वेरी

एग्रीगेट क्या होते हैं और इनका इस्तेमाल क्यों किया जाता है?

एग्रीगेट किए गए फ़ील्ड की मदद से, नतीजों की सूची पर कैलकुलेशन की जा सकती है. एग्रीगेट फ़ील्ड की मदद से, ये काम किए जा सकते हैं:

• समीक्षा का औसत स्कोर देखना
• शॉपिंग कार्ट में मौजूद आइटम की कुल कीमत देखना
• सबसे अच्छी या सबसे खराब रेटिंग वाला प्रॉडक्ट ढूंढना
• अपने स्टोर में मौजूद प्रॉडक्ट की संख्या देखना

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

• ऐप्लिकेशन की तेज़ परफ़ॉर्मेंस (क्लाइंट साइड पर कैलकुलेशन की ज़रूरत नहीं पड़ती)
• डेटा एक्सग्रेस की लागत कम हो जाती है. ऐसा इसलिए होता है, क्योंकि सभी इनपुट के बजाय सिर्फ़ एग्रीगेट किए गए नतीजे भेजे जाते हैं
• बेहतर सुरक्षा (क्योंकि क्लाइंट को पूरे डेटा सेट के बजाय, इकट्ठा किए गए डेटा का ऐक्सेस दिया जा सकता है)

एग्रीगेट के लिए स्कीमा का उदाहरण

इस सेक्शन में, हम स्टोरफ़्रंट के उदाहरण वाले स्कीमा पर स्विच करेंगे. यह एग्रीगेट इस्तेमाल करने का तरीका बताने के लिए एक अच्छा उदाहरण है:

  type Product @table {
    name: String!
    manufacturer: String!
    quantityInStock: Int!
    price: Float!
    expirationDate: Date
  }

सामान्य एग्रीगेट

सभी फ़ील्ड के लिए _count

सबसे आसान एग्रीगेट फ़ील्ड _count है: यह दिखाता है कि आपकी क्वेरी से कितनी पंक्तियां मैच करती हैं. आपके टाइप के हर फ़ील्ड के लिए, Data Connect फ़ील्ड टाइप के आधार पर उससे जुड़े एग्रीगेट फ़ील्ड जनरेट करता है.

query CountProducts {
  products {
    _count
  }
}

{
  "products": [
    {
    "_count": 5
    }
  ]
}

सभी फ़ील्ड में एक <field>_count फ़ील्ड होता है. इससे यह पता चलता है कि कितनी पंक्तियों में उस फ़ील्ड में कोई वैल्यू मौजूद है.

query CountProductsWithExpirationDate {
  products {
    expirationDate_count
  }
}

{
  "products": [
    {
    "expirationDate_count": 3
    }
  ]
}

संख्या वाले फ़ील्ड के लिए _min, _max, _sum, और _avg

संख्या वाले फ़ील्ड (int, float, int64) में भी <field>_min, <field>_max, <field>_sum, और <field>_avg होते हैं.

query NumericAggregates {
  products {
  quantityInStock_max
  price_min
  price_avg
  quantityInStock_sum
  }
}

{
  "products": [
    {
    "quantityInStock_max": 20,
    "price_min": 1.99,
    "price_avg": 3.6566666666666666,
    "quantityInStock_sum": 35
    }
  ]
}

तारीखों और टाइमस्टैंप के लिए _min और _max

तारीख और टाइमस्टैंप फ़ील्ड में <field>_min और <field>_max होते हैं.

query DateAndTimeAggregates {
  products {
  expirationDate_max
  expirationDate_min
  }
}

{
  "products": [
    {
    "expirationDate_max": "2024-03-01",
    "expirationDate_min": "2024-01-01"
    }
  ]
}

अलग-अलग

distinct आर्ग्युमेंट की मदद से, किसी फ़ील्ड (या फ़ील्ड के कॉम्बिनेशन) की सभी यूनीक वैल्यू देखी जा सकती हैं. उदाहरण के लिए:

query ListDistinctManufacturers {
  products(distinct: true) {
    manufacturer
  }
}

{
  "products": [
    { "manufacturer": "Acme" },
    { "manufacturer": "Beta" }
  ]
}

अलग-अलग वैल्यू को एग्रीगेट करने के लिए, एग्रीगेट फ़ील्ड पर distinct आर्ग्युमेंट का इस्तेमाल भी किया जा सकता है. उदाहरण के लिए:

query CountDistinctManufacturers {
  products {
    manufacturer_count(distinct: true)
  }
}

{
  "products": [
    {
    "manufacturer_count": 2
    }
  ]
}

ग्रुप किए गए एग्रीगेटर

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

query MostExpensiveProductByManufacturer {
  products {
  manufacturer
  price_max
  }
}

{
  "products": [
    { "manufacturer": "Acme", "price_max": 2.99 },
    { "manufacturer": "Beta", "price_max": 5.99 }
  ]
}

ग्रुप किए गए एग्रीगेट के साथ having और where

having और where आर्ग्युमेंट का इस्तेमाल करके, सिर्फ़ उन ग्रुप को दिखाया जा सकता है जो दी गई शर्तों को पूरा करते हैं.

• having की मदद से, एग्रीगेट किए गए फ़ील्ड के हिसाब से ग्रुप फ़िल्टर किए जा सकते हैं

• where की मदद से, बिना एग्रीगेट किए गए फ़ील्ड के आधार पर लाइनों को फ़िल्टर किया जा सकता है.

query FilteredMostExpensiveProductByManufacturer {
  products(having: {price_max: {ge: 2.99}}) {
  manufacturer
  price_max
  }
}

{
  "products": [
    { "manufacturer": "Acme", "price_max": 2.99 },
    { "manufacturer": "Beta", "price_max": 5.99 }
  ]
}

सभी टेबल में एग्रीगेट

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

  type Product @table {
    name: String!
    manufacturer: Manufacturer!
    quantityInStock: Int!
    price: Float!
    expirationDate: Date
  }

  type Manufacturer @table {
    name: String!
    headquartersCountry: String!
  }

अब एग्रीगेट फ़ील्ड का इस्तेमाल करके, कई काम किए जा सकते हैं. जैसे, यह पता लगाना कि मैन्युफ़ैक्चरर कितने प्रॉडक्ट बनाता है:

query GetProductCount($id: UUID) {
  manufacturers {
    name
    products_on_manufacturer {
      _count
    }
  }
}

{
  "manufacturers": [
    { "name": "Acme", "products_on_manufacturer": { "_count": 2 } },
    { "name": "Beta", "products_on_manufacturer": { "_count": 1 } }
  ]
}

फ़िल्म की समीक्षा के डेटाबेस के लिए म्यूटेशन

जैसा कि बताया गया है, अपने स्कीमा में टेबल तय करने पर, Data Connect हर टेबल के लिए बुनियादी _insert, _update वगैरह फ़ील्ड जनरेट करेगा.

type Movie @table { ... }

extend type Mutation {
  # Insert a row into the movie table.
  movie_insert(...): Movie_Key!
  # Upsert a row into movie."
  movie_upsert(...): Movie_Key!
  # Update a row in Movie. Returns null if a row with the specified id/key does not exist
  movie_update(...): Movie_Key
  # Update rows based on a filter in Movie.
  movie_updateMany(...): Int!
  # Delete a single row in Movie. Returns null if a row with the specified id/key does not exist
  movie_delete(...): Movie_Key
  # Delete rows based on a filter in Movie.
  movie_deleteMany(...): Int!
}

इनकी मदद से, CRUD के ज़्यादा जटिल कोर केस लागू किए जा सकते हैं. इसे तेज़ी से पांच बार बोलें!

बनाएं

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

# 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
    }
  })
}

Data Connect में फ़ील्ड अपडेट के लिए, ये ऑपरेटर काम करते हैं:

• inc, Int, Int64, Float, Date, और Timestamp डेटा टाइप को बढ़ाने के लिए
• 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 }
  )
}

Data Connect को field_expr सिंटैक्स का इस्तेमाल करके वैल्यू देने की अनुमति दें

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

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

म्यूटेशन लागू करते समय, field_expr सिंटैक्स का इस्तेमाल करके, सर्वर से जनरेट किए गए अपडेट को ट्रिगर करें या अनुरोधों से डेटा ऐक्सेस करें. उदाहरण के लिए, किसी अनुरोध में सेव की गई अनुमति uid को _upsert ऑपरेशन में पास करने के लिए, 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 स्केलर देखें.

कई चरणों में होने वाली कार्रवाइयां

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

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

• एक से ज़्यादा 'लिखें' फ़ील्ड

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

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

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

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

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

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

इस नतीजे से बचने के लिए, जांचें कि @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 म्यूटेशन को कॉल करें.

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

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

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

• डेटाबेस के ऑपरेशन काम न कर सकते.
• क्वेरी @check लॉजिक की वजह से, ऑपरेशन बंद हो सकते हैं.

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

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

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

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

मिलता-जुलता एसक्यूएल स्कीमा

-- Movies Table
CREATE TABLE Movies (
    movie_id UUID DEFAULT uuid_generate_v4() PRIMARY KEY,
    title VARCHAR(255) NOT NULL,
    release_year INT,
    genre VARCHAR(30),
    rating INT,
    description TEXT,
    tags TEXT[]
);
-- Movie Metadata Table
CREATE TABLE MovieMetadata (
    movie_id UUID REFERENCES Movies(movie_id) UNIQUE,
    director VARCHAR(255) NOT NULL,
    PRIMARY KEY (movie_id)
);
-- Actors Table
CREATE TABLE Actors (
    actor_id UUID DEFAULT uuid_generate_v4() PRIMARY KEY,
    name VARCHAR(30) NOT NULL
);
-- MovieActor Join Table for Many-to-Many Relationship
CREATE TABLE MovieActor (
    movie_id UUID REFERENCES Movies(movie_id),
    actor_id UUID REFERENCES Actors(actor_id),
    role VARCHAR(50) NOT NULL, # "main" or "supporting"
    PRIMARY KEY (movie_id, actor_id),
    FOREIGN KEY (movie_id) REFERENCES Movies(movie_id),
    FOREIGN KEY (actor_id) REFERENCES Actors(actor_id)
);
-- Users Table
CREATE TABLE Users (
    user_id UUID DEFAULT uuid_generate_v4() PRIMARY KEY,
    user_auth VARCHAR(255) NOT NULL
    username VARCHAR(30) NOT NULL
);
-- Reviews Table
CREATE TABLE Reviews (
    review_id UUID DEFAULT uuid_generate_v4() PRIMARY KEY,
    user_id UUID REFERENCES Users(user_id),
    movie_id UUID REFERENCES Movies(movie_id),
    rating INT,
    review_text TEXT,
    review_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    UNIQUE (movie_id, user_id)
    FOREIGN KEY (user_id) REFERENCES Users(user_id),
    FOREIGN KEY (movie_id) REFERENCES Movies(movie_id)
);
-- Self Join Example for Movie Sequel Relationship
ALTER TABLE Movies
ADD COLUMN sequel_to UUID REFERENCES Movies(movie_id);

आगे क्या करना है?

• अनुमति और पुष्टि की मदद से, अपनी क्वेरी और म्यूटेशन को सुरक्षित बनाने का तरीका जानें.
• अपने-आप जनरेट हुए वेब SDK टूल, Android SDK टूल, iOS SDK टूल, और Flutter SDK टूल से अपनी क्वेरी और म्यूटेशन को कॉल करने का तरीका जानें.