Schematy, zapytania i mutacje Data Connect

Firebase Data Connect umożliwia tworzenie złączeń dla instancji PostgreSQL zarządzanych za pomocą Google Cloud SQL. Te łączniki to kombinacje schematu, zapytań i mutacji służących do korzystania z Twoich danych.

W przewodniku wprowadzającym przedstawiono schemat aplikacji do recenzowania filmów dla PostgreSQL. Ten przewodnik zawiera bardziej szczegółowe informacje o projektowaniu schematów Data Connect dla PostgreSQL.

Ten przewodnik łączy zapytania i mutacje Data Connect z przykładami schematów. Dlaczego w przewodniku dotyczącym schematów Data Connect omawiamy zapytania (i mutacje)? Podobnie jak inne platformy oparte na GraphQL, Firebase Data Connect jest platformą programistyczną opartą na zapytaniach. Dlatego jako programista podczas modelowania danych musisz mieć na uwadze potrzeby swoich klientów, które będą miały duży wpływ na schemat danych opracowany na potrzeby projektu.

Ten przewodnik zaczyna się od nowego schematu do recenzji filmów, a następnie omawia zapytania i mutacje wyprowadzone z tego schematu. Na końcu zawiera listę kodu SQL odpowiadającą głównemu schematowi Data Connect.

Schemat aplikacji do recenzowania filmów

Załóżmy, że chcesz stworzyć usługę, która umożliwia użytkownikom przesyłanie i wyświetlanie recenzji filmów.

W przypadku takiej aplikacji potrzebujesz wstępnego schematu, który później rozszerzysz, aby tworzyć złożone zapytania relacyjne.

Tabela Film

Schemat dotyczący filmów zawiera podstawowe dyrektywy, takie jak:

  • @table, która pozwala nam ustawiać nazwy operacji za pomocą argumentów singular i plural
  • @col do jawnego ustawiania nazw kolumn;
  • @default, aby zezwolić na ustawianie domyślnych wartości.
# 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")
}

Wartości serwera i klucze skalarne

Zanim przyjrzymy się aplikacji z recenzjami filmów, przedstawimy Data Connectwartości serwera i klucze skalarne.

Korzystając z wartości serwera, możesz pozwolić serwerowi na dynamiczne wypełnianie pól w tabelach za pomocą zapisanych lub łatwo obliczalnych wartości zgodnie z określonymi wyrażeniami po stronie serwera. Możesz na przykład zdefiniować pole z dodaną sygnaturą czasową, gdy uzyskujesz do niego dostęp za pomocą wyrażenia updatedAt: Timestamp! @default(expr: "request.time").

Kluczowe skalary to zwięzłe identyfikatory obiektów, które Data Connect automatycznie generuje na podstawie kluczowych pól w schematach. Kluczowe skalary dotyczą wydajności i pozwalają znaleźć w jednym wywołaniu informacje o tożsamości i strukturze danych. Są one szczególnie przydatne, gdy chcesz wykonywać sekwencyjne działania na nowych rekordach i potrzebujesz unikalnego identyfikatora, który będziesz przekazywać do kolejnych operacji, a także gdy chcesz uzyskać dostęp do kluczy relacyjnych, aby wykonywać dodatkowe, bardziej złożone operacje.

Tabela metadanych filmu

Teraz śledźmy reżyserów filmowych i ustawiamy relację jeden-do-jednego z Movie.

Aby zdefiniować relacje, dodaj dyrektywę @ref.

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

Actor i MovieActor

Następnie chcesz, aby aktorzy występowali w Twoich filmach. Ponieważ istnieje relacja „wiele do wielu” między filmami a aktorami, utwórz tabelę złączeń.

# 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(name: "Actors", singular: "actor", plural: "actors") {
  id: UUID! @col(name: "actor_id") @default(expr: "uuidV4()")
  name: String! @col(name: "name", dataType: "varchar(30)")
}
# Join table for many-to-many relationship for movies and actors
# The 'key' param signifies the primary key(s) of this table
# In this case, the keys are [movieId, actorId], the generated fields of the reference types [movie, actor]
type MovieActor @table(key: ["movie", "actor"]) {
  # @ref creates a field in the current table (MovieActor) 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, see: implicit.gql
  actor: Actor! @ref
  # actorId: UUID! <- this is created by the above @ref, see: implicit.gql
  role: String! @col(name: "role") # "main" or "supporting"
  # optional other fields
}

Użytkownik

Na koniec użytkownicy Twojej aplikacji.

# Users
# Suppose a user can leave reviews for movies
# user:reviews is a one to many relationship, movie:reviews is a one to many relationship, movie:user is a many to many relationship
type User
  @table(name: "Users", singular: "user", plural: "users", key: ["id"]) {
  id: UUID! @col(name: "user_id") @default(expr: "uuidV4()")
  auth: String @col(name: "user_auth") @default(expr: "auth.uid")
  username: String! @col(name: "username", dataType: "varchar(30)")
  # The following are generated from the @ref in the Review table
  # reviews_on_user
  # movies_via_Review
}

Obsługiwane typy danych

Data Connect obsługuje te typy danych skalarnych, przypisując je do typów PostgreSQL za pomocą funkcji @col(dataType:).

Data Connect typ Wbudowany typ GraphQL lub
Data Connect niestandardowy typ 		Domyślny typ PostgreSQL Obsługiwane typy PostgreSQL
(alias w nawiasach)
Ciąg znaków GraphQL tekst text
bit(n), varbit(n)
char(n), varchar(n)
Liczba całkowita GraphQL int, Int2 (smallint, smallserial),
int4 (integer, int, serial)
Liczba zmiennoprzecinkowa GraphQL float8 float4 (real)
float8 (podwójna precyzja)
numeric (dziesiętna)
Wartość logiczna GraphQL wartość logiczna wartość logiczna
UUID Niestandardowy identyfikator UUID identyfikator UUID
Int64 Niestandardowy bigint int8 (bigint, bigserial)
numeric (dziesiętna)
Data Niestandardowy date data
Sygnatura czasowa Niestandardowy timestamptz

timestamptz

Uwaga: informacje o lokalnej strefie czasowej nie są przechowywane.
PostgreSQL konwertuje i przechowuje takie sygnatury czasowe jako czas UTC.
Wektor Niestandardowy wektor

wektor

Zapoznaj się z artykułem Wyszukiwanie wektorów o podobnych cechach w Vertex AI.
  • Parametr GraphQL List jest mapowany na tablicę jednowymiarową.
    • Na przykład [Int] jest mapowane na int5[], a [Any] na jsonb[].
    • Data Connect nie obsługuje zagnieżdżonych tablic.

Zapytania i mutacje domyślne i zdefiniowane wstępnie

Zapytania i mutacje Data Connect rozszerzają zestaw domyślnych zapytań i domyślnych mutacji wygenerowanych przez Data Connect na podstawie typów i ich wzajemnych relacji w schemacie. Za każdym razem, gdy edytujesz schemat, zapytania i mutacje domyślne są generowane przez narzędzia lokalne.

W procesie tworzenia zaimplementujesz zdefiniowane wstępnie zapytania i zdefiniowane wstępnie mutacje na podstawie tych operacji domyślnych.

Nazewnictwo zapytań i mutacji pośrednich

Data Connect wyprowadza odpowiednie nazwy dla zapytań i mutacji domyślnych na podstawie deklaracji typu schematu. Jeśli na przykład pracujesz z źródłem PostgreSQL i zdefiniujesz tabelę o nazwie Movie, serwer wygeneruje domyślnie:

  • Zapytania dotyczące pojedynczej tabeli mają przyjazne nazwy movie (liczba pojedyncza) i movies (liczba mnoga) (do pobierania poszczególnych wyników z argumentami takimi jak eq oraz do pobierania list wyników z argumentami takimi jak gt i operacjami takimi jak orderby). Data Connect generuje też zapytania dotyczące operacji relacyjnych obejmujących wiele tabel o wyraźnych nazwach, np. actors_on_movies lub actors_via_actormovie.
  • Mutacje o nazwach movie_insert, movie_upsert...

Język definiowania schematów umożliwia też jawne ustawianie nazw operacji za pomocą argumentów dyrektyw singular i plural.

Wskazówki dotyczące zapytań i mutacji

Oprócz dyrektyw używanych do definiowania typów i tabel Data Connect udostępnia dyrektywy @auth, @check, @redact i @transaction, które służą do rozszerzania działania zapytań i mutacji.

Dyrektywa Dotyczy Opis
@auth Zapytania i mutacje Określa zasadę uwierzytelniania dla zapytania lub operacji. Zapoznaj się z przewodnikiem dotyczącym autoryzacji i poświadczenia.
@check Zapytania dotyczące danych autoryzacji Sprawdza, czy określone pola występują w wynikach zapytania. Do testowania wartości pól służy wyrażenie w języku Common Expression Language (CEL). Zapoznaj się z przewodnikiem dotyczącym autoryzacji i poświadczenia.
@redact Zapytania Częściowo zamazuje odpowiedź klienta. Zapoznaj się z przewodnikiem dotyczącym autoryzacji i poświadczenia.
@transaction Mutacje Wymusza, aby mutacja zawsze była wykonywana w ramach transakcji bazy danych. Zobacz przykłady mutacji w aplikacji do tworzenia filmów.

zapytania do bazy danych z recenzjami filmowymi;

Zapytanie Data Connect definiujesz za pomocą deklaracji typu operacji zapytania, nazwy operacji, co najmniej 1 argumentu operacji i co najmniej 1 dyrektywy z argumentami.

W pliku wprowadzającym przykładowe zapytanie listEmails nie zawierało żadnych parametrów. Oczywiście w wielu przypadkach dane przekazywane do pól zapytania będą dynamiczne. Aby używać zmiennych jako jednego z elementów definicji zapytania, możesz używać składni $variableName.

.

Zapytanie zawiera:

  • Definicja typu query
  • Nazwa operacji (zapytania) ListMoviesByGenre
  • Argument operacji $genre o jednej zmiennej
  • Pojedyncza dyrektywa @auth.
query ListMoviesByGenre($genre: String!) @auth(level: USER)

Każdy argument zapytania wymaga deklaracji typu, wbudowanego, np. String, lub niestandardowego typu zdefiniowanego w schemacie, np. Movie.

Przyjrzyjmy się sygnaturom coraz bardziej złożonych zapytań. Na koniec poznasz potężne i zwięzłe wyrażenia relacji dostępne w zapytaniach domyślnych, które możesz stosować w swoich wstępnie zdefiniowanych zapytaniach.

Kluczowe skalary w zapytaniach

Najpierw jednak kilka uwag na temat kluczowych skalarów.

Data Connect definiuje specjalny typ dla kluczowych wartości skalarnych, identyfikowanych przez _Key. Na przykład typ skalarnego klucza w tabeli Movie to Movie_Key.

Kluczowe skalary są pobierane jako odpowiedź zwracana przez większość niejawnych mutacji lub oczywiście z zapytań, w których pobrane zostały wszystkie pola potrzebne do utworzenia klucza skalarnego.

Pojedyncze zapytania automatyczne, takie jak movie w naszym przykładzie, obsługują argument klucza, który przyjmuje klucz skalarny.

Możesz przekazać klucz skalarny jako literał. Możesz jednak zdefiniować zmienne, które będą przekazywane jako wejście do kluczy skalarnych.

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

Można je podać w pliku JSON żądania w ten sposób (lub w innych formatach serializacji):

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

Dzięki niestandardowemu parsowaniu skalarnemu element Movie_Key można też utworzyć za pomocą składni obiektu, która może zawierać zmienne. Jest to przydatne głównie wtedy, gdy z jakiegoś powodu chcesz podzielić poszczególne komponenty na różne zmienne.

Aliasowanie w zapytaniach

Data Connect obsługuje w zapytaniach aliasowanie GraphQL. Za pomocą aliasów możesz zmieniać nazwy danych zwracanych w wynikach zapytania. Pojedyncze zapytanie Data Connect może stosować wiele filtrów lub innych operacji zapytań w jednym skutecznym żądaniu wysłanym do serwera, co w efekcie powoduje wysłanie kilku „podzapytań” naraz. Aby uniknąć kolizji nazw w zwróconym zbiorze danych, możesz używać aliasów do odróżniania zapytań podrzędnych.

Oto zapytanie, w którym wyrażenie używa aliasu mostPopular.

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

proste zapytania z filtrami,

Zapytania Data Connect są mapowane na wszystkie typowe filtry SQL i operacje sortowania.

Operatory where i orderBy (zapytania w liczbie pojedynczej i mnożnej)

Zwraca wszystkie dopasowane wiersze z tabeli (i zagnieżdżone powiązania). Jeśli żaden rekord nie pasuje do filtra, zwraca pustą tablicę.

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}]) { … }
}

Operatory limit i offset (zapytania w liczbie pojedynczej i mnożnej)

Możesz podzielić wyniki na strony. Te argumenty są akceptowane, ale nie są zwracane w wynikach.

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

zawiera w przypadku pól tablicowych.

Możesz sprawdzić, czy pole tablicy zawiera określony element.

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

Operacje na ciągach znaków i wyrażenia regularne

Zapytania mogą używać typowych operacji wyszukiwania i porównywania ciągów znaków, w tym wyrażeń regularnych. Uwaga: ze względu na wydajność łączysz tutaj kilka operacji i rozróżniasz je za pomocą aliasów.

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 i and w przypadku złożonych filtrów

W przypadku bardziej złożonej logiki użyj znaczników or i 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
  }
}

Zapytania złożone

Zapytania Data Connect mogą uzyskiwać dostęp do danych na podstawie relacji między tabelami. Możesz używać zdefiniowanych w schemacie relacji obiektu (jeden do jednego) lub tablicy (jeden do wielu) do tworzenia zapytań zagnieżdżonych, czyli pobierania danych o jednym typie wraz z danymi o typie zagnieżdżonym lub powiązanym.

Takie zapytania używają w generowanych zapytaniach domyślnych składni magicznej Data Connect _on_ i _via.

Wprowadzisz zmiany w schemacie z naszej początkowej wersji.

Wiele do jednego

Dodajmy opinie do naszej aplikacji, korzystając z tabeli Review i modyfikacji User.

# Users
# Suppose a user can leave reviews for movies
# user:reviews is a one to many relationship,
# movie:reviews is a one to many relationship,
# movie:user is a many to many relationship
type User
  @table(name: "Users", singular: "user", plural: "users", key: ["id"]) {
  id: UUID! @col(name: "user_id") @default(expr: "uuidV4()")
  auth: String @col(name: "user_auth") @default(expr: "auth.uid")
  username: String! @col(name: "username", dataType: "varchar(30)")
  # The following are generated from the @ref in the Review table
  # reviews_on_user
  # movies_via_Review
}
# Reviews
type Review @table(name: "Reviews", key: ["movie", "user"]) {
  id: UUID! @col(name: "review_id") @default(expr: "uuidV4()")
  user: User! @ref
  movie: Movie! @ref
  rating: Int
  reviewText: String
  reviewDate: Date! @default(expr: "request.time")
}

Zapytanie „wielu do jednego”

Aby zilustrować składnię _via_, przyjrzyjmy się zapytaniu z aliasem.

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

Jeden na jeden

Możesz zobaczyć wzór. Poniżej przedstawiamy zmodyfikowany schemat.

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

Zapytanie dotyczące rozmów twarzą w twarz

Możesz wysłać zapytanie przy użyciu składni _on_.

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

wiele do wielu

Filmy potrzebują aktorów, a aktorzy potrzebują filmów. Łączy je relacja „wiele do wielu”, którą możesz modelować za pomocą tabeli złączeń 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!]!
}

Zapytanie dotyczące relacji „wiele do wielu”

Aby zilustrować składnię _via_, przyjrzyjmy się zapytaniu z aliasem.

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

Mutacje w bazie danych z recenzjami filmowymi

Jak już wspomnieliśmy, po zdefiniowaniu tabeli w schemacie Data Connect wygeneruje podstawowe domyślne mutacje dla każdej tabeli.

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!
}

Dzięki nim możesz wdrażać coraz bardziej złożone podstawowe przypadki użycia CRUD. Powtórz to 5 razy szybko.

.

Dyrektywa @transaction

Ta dyrektywa nakazuje, aby mutacja zawsze była wykonywana w ramach transakcji bazy danych.

Mutacje z wartością @transaction mają zagwarantowany albo pełny sukces, albo całkowitą porażkę. Jeśli jakiekolwiek pole w transakcji nie powiedzie się, cała transakcja zostanie wycofana. Z punktu widzenia klienta każde niepowodzenie działa tak, jakby całe żądanie zakończyło się niepowodzeniem z błędem żądania i nie rozpoczęto jego wykonywania.

Mutacje bez @transaction wykonują każde pole główne po kolei. Wyświetla on wszystkie błędy jako błędy częściowych pól, ale nie wyświetla wpływu na kolejne wykonania.

Utwórz

Zajmijmy się podstawami tworzenia.

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

lub zaktualizowane.

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

Wykonywanie aktualizacji

Oto aktualności. Producenci i reżyserzy z pewnością mają nadzieję, że te średnie oceny są zgodne z trendami.

mutation UpdateMovie(
  $id: UUID!,
  $genre: String!,
  $rating: Int!,
  $description: String!
) {
  movie_update(id: $id, data: {
    genre: $genre
    rating: $rating
    description: $description
  })
}

# Multiple updates (increase all ratings of a genre)
mutation IncreaseRatingForGenre($genre: String!, $ratingIncrement: Int!) {
  movie_updateMany(
    where: { genre: { eq: $genre } },
    update: { rating: { inc: $ratingIncrement } }
  )
}

Usuwanie

Możesz oczywiście usunąć dane filmu. Osoby zajmujące się konserwacją filmów z pewnością chcą, aby fizyczne filmy były utrzymywane tak długo, jak to możliwe.

# Delete by key
mutation DeleteMovie($id: UUID!) {
  movie_delete(id: $id)
}

Możesz tu użyć _deleteMany.

# Multiple deletes
mutation DeleteUnpopularMovies($minRating: Int!) {
  movie_deleteMany(where: { rating: { le: $minRating } })
}

Napisz mutacje relacji

Zobacz, jak zastosować do relacji domyślną operację _upsert.

# Create or update a one to one relation
mutation MovieMetadataUpsert($movieId: UUID!, $director: String!) {
  movieMetadata_upsert(
    data: { movie: { id: $movieId }, director: $director }
  )
}

Zapytania dotyczące danych autoryzacji

Zmiany typu Data Connect można autoryzować, najpierw wysyłając zapytanie do bazy danych i sprawdzając wyniki zapytania za pomocą wyrażeń CEL. Jest to przydatne, gdy zapisujesz dane w tabeli i musisz sprawdzić zawartość wiersza w innej tabeli.

Ta funkcja obsługuje:

  • dyrektywa @check, która umożliwia ocenę zawartości pól i na podstawie wyników tej oceny:
    • Przejdź do tworzenia, aktualizowania i usuwania elementów zdefiniowanych przez operację.
    • Używanie wartości zwracanych klientom przez zapytanie do wykonywania różnych operacji logicznych na klientach
  • dyrektywa @redact, która umożliwia pomijanie wyników zapytań w wynikach protokołu sieciowego;

Te funkcje są przydatne w procesach autoryzacji.

Odpowiednik w schemie SQL

-- 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);

Co dalej?