Data Connect के लिए कॉमन एक्सप्रेशन लैंग्वेज सिंटैक्स का रेफ़रंस

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

इस रेफ़रंस गाइड में, @auth(expr:) और @check(expr:) निर्देशों के लिए एक्सप्रेशन बनाने के लिए, कॉमन एक्सप्रेशन लैंग्वेज (सीईएल) सिंटैक्स के बारे में बताया गया है.

सीईएल के लिए रेफ़रंस की पूरी जानकारी, सीईएल स्पेसिफ़िकेशन में दी गई है.

क्वेरी और म्यूटेशन में पास किए गए वैरिएबल की जांच करना

@auth(expr) सिंटैक्स की मदद से, क्वेरी और बदलावों से वैरिएबल ऐक्सेस किए जा सकते हैं और उनकी जांच की जा सकती है.

उदाहरण के लिए, vars.status का इस्तेमाल करके, $status जैसे ऑपरेशन वैरिएबल को शामिल किया जा सकता है.

mutation Update($id: UUID!, $status: Any) @auth(expr: "has(vars.status)")

एक्सप्रेशन के लिए उपलब्ध डेटा: request, response, this

डेटा का इस्तेमाल इन कामों के लिए किया जाता है:

• @auth(expr:) और @check(expr:) निर्देशों में सीईएल एक्सप्रेशन की मदद से आकलन
• सर्वर एक्सप्रेशन का इस्तेमाल करके असाइनमेंट, <field>_expr.

@auth(expr:) और @check(expr:), दोनों सीईएल एक्सप्रेशन इनका आकलन कर सकते हैं:

• request.operationName
• vars (request.variables का उपनाम)
• auth (request.auth का उपनाम)

म्यूटेशन में, इनके कॉन्टेंट को ऐक्सेस और असाइन किया जा सकता है:

• response (एक से ज़्यादा चरणों वाले लॉजिक में कुछ नतीजे देखने के लिए)

इसके अलावा, @check(expr:) एक्सप्रेशन इनका आकलन कर सकते हैं:

• this (मौजूदा फ़ील्ड की वैल्यू)
• response (एक से ज़्यादा चरणों वाले लॉजिक में कुछ नतीजे देखने के लिए)

request.operationName बाइंडिंग

request.operarationName बाइंडिंग, क्वेरी या बदलाव, दोनों में से किसी एक तरह के ऑपरेशन को सेव करती है.

vars बाइंडिंग (request.vars)

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

किसी एक्सप्रेशन में, vars.<variablename> का इस्तेमाल पूरी तरह से तय किए गए request.variables.<variablename> के लिए, किसी दूसरे नाम के तौर पर किया जा सकता है:

# The following are equivalent
mutation StringType($v: String!) @auth(expr: "vars.v == 'hello'")
mutation StringType($v: String!) @auth(expr: "request.variables.v == 'hello'")

auth बाइंडिंग (request.auth)

Authentication, आपके डेटा को ऐक्सेस करने का अनुरोध करने वाले उपयोगकर्ताओं की पहचान करता है और उस जानकारी को एक बाइंडिंग के तौर पर उपलब्ध कराता है. इस बाइंडिंग का इस्तेमाल, एक्सप्रेशन में किया जा सकता है.

अपने फ़िल्टर और एक्सप्रेशन में, auth का इस्तेमाल request.auth के लिए किसी दूसरे नाम के तौर पर किया जा सकता है.

पुष्टि करने वाले बाइंडिंग में यह जानकारी शामिल होती है:

• uid: अनुरोध करने वाले उपयोगकर्ता को असाइन किया गया यूनीक यूज़र आईडी.
• token: Authentication से इकट्ठा की गई वैल्यू का मैप.

auth.token के कॉन्टेंट के बारे में ज़्यादा जानकारी के लिए, पुष्टि करने वाले टोकन में मौजूद डेटा देखें

response बाइंडिंग

response बाइंडिंग में, क्वेरी या म्यूटेशन के जवाब में, सर्वर से इकट्ठा किया जा रहा डेटा शामिल होता है. यह डेटा इकट्ठा होने के दौरान ऐसा होता है.

ऑपरेशन के आगे बढ़ने के साथ-साथ, हर चरण के पूरा होने पर, response में पूरे हो चुके चरणों का रिस्पॉन्स डेटा शामिल होता है.

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

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

उदाहरण के लिए:

• एम्बेड की गई क्वेरी वाले म्यूटेशन में, response बिडिंग में response.query.<fieldName>.<fieldName>.... पर लुकअप डेटा होता है. इस मामले में, response.query.todoList और response.query.todoList.priority.

mutation CheckTodoPriority(
  $uniqueListName: String!
) {
  # This query is identified as `response.query`
  query @check(expr: "response.query.todoList.priority == 'high'", message: "This list is not for high priority items!") {
    # This field is identified as `response.query.todoList`
    todoList(where: { name: $uniqueListName }) {
      # This field is identified as `response.query.todoList.priority`
      priority
    }
  }
}

• कई चरणों वाले म्यूटेशन में, उदाहरण के लिए, कई _insert फ़ील्ड के साथ, response बाइंडिंग में response.<fieldName>.<fieldName>.... पर कुछ डेटा होता है. इस मामले में, response.todoList_insert.id.

mutation CreateTodoListWithFirstItem(
  $listName: String!,
  $itemContent: String!
) @transaction {
  # Step 1
  todoList_insert(data: {
    id_expr: "uuidV4()",
    name: $listName,
  })
  # Step 2:
  todo_insert(data: {
    listId_expr: "response.todoList_insert.id" # <-- Grab the newly generated ID from the partial response so far.
    content: $itemContent,
  })
}

this बाइंडिंग

बाइंडिंग this उस फ़ील्ड का आकलन करता है जिससे @check डायरेक्टिव जुड़ा है. सामान्य मामले में, एक वैल्यू वाली क्वेरी के नतीजों का आकलन किया जा सकता है.

mutation UpdateMovieTitle (
  $movieId: UUID!,
  $newTitle: String!)
  @auth(level: USER)
  @transaction {
  # Step 1: Query and check
  query @redact {
    moviePermission( # Look up a join table called MoviePermission with a compound key.
      key: {movieId: $movieId, userId_expr: "auth.uid"}
    ) {
      # Check if the user has the editor role for the movie. `this` is the string value of `role`.
      # If the parent moviePermission is null, the @check will also fail automatically.
      role @check(expr: "this == 'editor'", message: "You must be an editor of this movie to update title")
    }
  }
  # Step 2: Act
  movie_update(id: $movieId, data: {
    title: $newTitle
  })
}

अगर कोई पैरंट एलिमेंट सूची है, तो रिटर्न किया गया फ़ील्ड कई बार दिख सकता है. ऐसे में, हर वैल्यू के साथ बाउंड किए गए this की मदद से, हर बार दिखने वाले फ़ील्ड की जांच की जाती है.

किसी भी पाथ के लिए, अगर कोई पैरंट null या [] है, तो फ़ील्ड तक नहीं पहुंचा जा सकेगा और उस पाथ के लिए सीईएल का आकलन नहीं किया जाएगा. दूसरे शब्दों में, आकलन सिर्फ़ तब होता है, जब this null या नॉन-null हो, लेकिन कभी भी undefined नहीं.

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

mutation UpdateMovieTitle2($movieId: UUID!, $newTitle: String!) @auth(level: USER) @transaction {
  # Step 1: Query and check
  query {
    moviePermissions( # Now we query for a list of all matching MoviePermissions.
      where: {movieId: {eq: $movieId}, userId: {eq_expr: "auth.uid"}}
    # This time we execute the @check on the list, so `this` is the list of objects.
    # We can use the `.exists` macro to check if there is at least one matching entry.
    ) @check(expr: "this.exists(p, p.role == 'editor')", message: "You must be an editor of this movie to update title") {
      role
    }
  }
  # Step 2: Act
  movie_update(id: $movieId, data: {
    title: $newTitle
  })
}

कॉम्प्लेक्स एक्सप्रेशन का सिंटैक्स

&& और || ऑपरेटर को मिलाकर, ज़्यादा जटिल एक्सप्रेशन लिखे जा सकते हैं.

mutation UpsertUser($username: String!) @auth(expr: "(auth != null) && (vars.username == 'joe')")

यहां दिए गए सेक्शन में, सभी उपलब्ध ऑपरेटर के बारे में बताया गया है.

ऑपरेटर और ऑपरेटर की प्राथमिकता

ऑपरेटर और उनके क्रम के रेफ़रंस के लिए, नीचे दी गई टेबल का इस्तेमाल करें.

a और b एक्सप्रेशन, f फ़ील्ड, और i इंडेक्स.

पुष्टि करने वाले टोकन में डेटा

auth.token ऑब्जेक्ट में ये वैल्यू हो सकती हैं:

JWT आईडी टोकन में अतिरिक्त फ़ील्ड

यहां दिए गए auth.token फ़ील्ड भी ऐक्सेस किए जा सकते हैं: