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

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

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

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

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

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

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

एक्सप्रेशन के लिए उपलब्ध डेटा: अनुरोध, जवाब, यह

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

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

@auth(expr:), @check(expr:), @refresh(onMutationExecuted:) सीईएल एक्सप्रेशन, इनकी जांच कर सकते हैं:

• request.operationName
• vars (request.variables का दूसरा ईमेल पता)
• auth (request.auth का दूसरा ईमेल पता)

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

• response (मल्टी-स्टेप लॉजिक में, आंशिक नतीजों की जांच करने के लिए)

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

• this (मौजूदा फ़ील्ड की वैल्यू)
• response (मल्टी-स्टेप लॉजिक में, आंशिक नतीजों की जांच करने के लिए)

साथ ही, @refresh(onMutationExecuted:) एक्सप्रेशन में यह बाइंडिंग होती है:

• mutation.variables
• mutation.auth

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 के इन फ़ील्ड को भी ऐक्सेस किया जा सकता है: