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

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

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

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

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

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

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

एक्सप्रेशन के लिए उपलब्ध डेटा: अनुरोध, जवाब, 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 के उपनाम के तौर पर किया जा सकता है.

auth बाइंडिंग में यह जानकारी शामिल होती है:

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

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

response बाइंडिंग

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

ऑपरेशन के आगे बढ़ने पर, हर चरण के सफलतापूर्वक पूरा होने पर, response में सफलतापूर्वक पूरे किए गए चरणों का जवाब डेटा शामिल होता है.

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

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

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

• किसी ऐसे म्यूटेशन में जिसमें एम्बेड की गई क्वेरी शामिल है, 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 के इन फ़ील्ड को भी ऐक्सेस किया जा सकता है: