データ統合

ビルドで Querydsl を構成するには、公式のリファレンスドキュメント (英語) に従ってください。

例:

QuerydslDataFetcher は、GraphQL 引数をプロパティにバインドして Querydsl Predicate を作成する方法のカスタマイズをサポートしています。デフォルトでは、引数は使用可能な各プロパティに対して「等しい」としてバインドされます。これをカスタマイズするには、QuerydslDataFetcher ビルダーメソッドを使用して QuerydslBinderCustomizer を提供します。

リポジトリ自体が QuerydslBinderCustomizer のインスタンスである場合があります。これは自動検出され、自動登録中に透過的に適用されます。ただし、手動で QuerydslDataFetcher をビルドする場合は、ビルダーメソッドを使用して適用する必要があります。

QuerydslDataFetcher はインターフェースと DTO 射影をサポートしてクエリ結果を変換してから、これらをさらに GraphQL 処理のために返します。

Querydsl リポジトリで Spring Data 射影を使用するには、射影 インターフェースまたはターゲット DTO クラスのいずれかを作成し、projectAs メソッドを介して構成して、ターゲット型を生成する DataFetcher を取得します。

リポジトリに @GraphQlRepository のアノテーションが付けられている場合、DataFetcher がまだ登録されておらず、戻り値の型がリポジトリのドメイン型と一致するクエリに対して自動的に登録されます。これには、単一値クエリ、複数値クエリ、ページ分割されたクエリが含まれます。

デフォルトでは、クエリによって返される GraphQL 型の名前は、リポジトリドメイン型の単純な名前と一致する必要があります。必要に応じて、@GraphQlRepository の typeName 属性を使用して、ターゲットの GraphQL 型名を指定できます。

ページ分割されたクエリの場合、リポジトリドメイン型の単純名は、末尾 Connection を除いた Connection 型名と一致する必要があります (例: Book は BooksConnection と一致します)。自動登録の場合、ページ分割はオフセットベースで、1 ページあたり 20 項目になります。

自動登録は、特定のリポジトリが QuerydslBinderCustomizer を実装しているかどうかを検出し、QuerydslDataFetcher ビルダーメソッドを介して透過的に適用します。

自動登録は、QuerydslDataFetcher から取得できる組み込みの RuntimeWiringConfigurer を介して実行されます。Boot スターターは @GraphQlRepository Bean を自動的に検出し、使用して RuntimeWiringConfigurer を初期化します。

リポジトリがそれぞれ QuerydslBuilderCustomizer または ReactiveQuerydslBuilderCustomizer を実装している場合、自動登録はリポジトリインスタンスで customize(Builder) を呼び出すことによってカスタマイズを適用します。

例示による問い合わせは、それがサポートされているデータストアの Spring Data モジュールにすでに含まれているため、有効にするために追加のセットアップは必要ありません。

QueryByExampleDataFetcher はインターフェースと DTO 射影をサポートしてクエリ結果を変換してから、これらをさらに GraphQL 処理のために返します。

例示による問い合わせ リポジトリで Spring Data 射影を使用するには、射影 インターフェースまたはターゲット DTO クラスのいずれかを作成し、projectAs メソッドを介して構成して、ターゲット型を生成する DataFetcher を取得します。

リポジトリに @GraphQlRepository のアノテーションが付けられている場合、DataFetcher がまだ登録されておらず、戻り値の型がリポジトリのドメイン型と一致するクエリに対して自動的に登録されます。これには、単一値クエリ、複数値クエリ、ページ分割されたクエリが含まれます。

デフォルトでは、クエリによって返される GraphQL 型の名前は、リポジトリドメイン型の単純な名前と一致する必要があります。必要に応じて、@GraphQlRepository の typeName 属性を使用して、ターゲットの GraphQL 型名を指定できます。

ページ分割されたクエリの場合、リポジトリドメイン型の単純名は、末尾 Connection を除いた Connection 型名と一致する必要があります (例: Book は BooksConnection と一致します)。自動登録の場合、ページ分割はオフセットベースで、1 ページあたり 20 項目になります。

自動登録は、QueryByExampleDataFetcher から取得できる組み込みの RuntimeWiringConfigurer を介して実行されます。Boot スターターは @GraphQlRepository Bean を自動的に検出し、使用して RuntimeWiringConfigurer を初期化します。

リポジトリがそれぞれ QueryByExampleBuilderCustomizer または ReactiveQueryByExampleBuilderCustomizer を実装している場合、自動登録はリポジトリインスタンスで customize(Builder) を呼び出すことによってカスタマイズを適用します。

The simplest approach to manage transactions is to use Spring’s Transaction Management together with @MutationMapping controller methods (or any other @SchemaMapping method) for example:

A transaction spans from entering the addAccount method until its return. All invocations to transactional resources are part of the same transaction resulting in atomicity and isolation of the mutation.

This is the recommended approach. It gives you full control over transaction boundaries with a clearly defined entrypoint without the need to instrument GraphQL server infrastructure.

Cleaning up a transaction after the method call results that subsequent data fetching (e.g. for nested fields) is not part of the transactional method addAccount as outlined below:

To run multiple mutations in a single transaction maintaining a simple setup we recommend designing a mutation method that accepts all required inputs. This method can then call multiple service methods, ensuring they all participate in the same transaction.

Applying a Transactional Instrumentation is a more advanced approach to span a transaction over the entire execution of a GraphQL request. By stating a transaction before the first data fetcher is invoked your application can ensure that all data fetchers can participate in the same transaction.

When instrumenting the server, you need to ensure an ExecutionStrategy runs DataFetcher invocations serially so that all invocations are executed on the same Thread. This is mandatory: Synchronous transaction management uses ThreadLocal state to allow participation in transactions. Considering AsyncSerialExecutionStrategy as starting point is a good choice as it executes data fetchers serially.

You have two general options to implement transactional instrumentation:

When manually managing transactions, ensure to clean up the transaction, that is either commiting or rolling back, after completing the unit of work. ExceptionWhileDataFetching can be a useful GraphQLError to obtain an underlying Exception. This error is constructed when using SimpleDataFetcherExceptionHandler. By default, Spring GraphQL falls back to an internal GraphQLError that doesn’t expose the original exception.

Applying transactional instrumentation creates opportunities to rethink transaction participation: All @SchemaMapping controller methods participate in the transaction regardless whether they are invoked for the root, nested fields, or as part of a mutation. Transactional controller methods (or service methods within the invocation chain) can declare transactional attributes such as propagation behavior REQUIRES_NEW to start a new transaction if required.