LazyInitializationException with graphql-spring

前端 未结 6 1368
庸人自扰
庸人自扰 2020-12-31 04:21

I am currently in the middle of migrating my REST-Server to GraphQL (at least partly). Most of the work is done, but i stumbled upon this problem which i seem to be unable t

6条回答
  •  一整个雨季
    2020-12-31 05:10

    I solved it and should have read the documentation of the graphql-java-tools library more carefully i suppose. Beside the GraphQLQueryResolver which resolves the basic queries i also needed a GraphQLResolver for my Showclass, which looks like this:

    @Component
    public class ShowResolver implements GraphQLResolver {
        @Autowired
        private CompetitionRepository competitionRepository;
    
        public List competitions(Show show) {
            return ((List)competitionRepository.findByShowId(show.getId()));
        }
    }
    

    This tells the library how to resolve complex objects inside my Showclass and is only used if the initially query requests to include the Competitionobjects. Happy new Year!

    EDIT 31.07.2019: I since stepped away from the solution below. Long running transactions are seldom a good idea and in this case it can cause problems once you scale your application. We started to implement DataLoaders to batch queries in an async matter. The long running transactions in combination with the async nature of the DataLoaders can lead to deadlocks: https://github.com/graphql-java-kickstart/graphql-java-tools/issues/58#issuecomment-398761715 (above and below for more information). I will not remove the solution below, because it might still be good starting point for smaller applications and/or applications which will not need any batched queries, but please keep this comment in mind when doing so.

    EDIT: As requested here is another solution using a custom execution strategy. I am using graphql-spring-boot-starter and graphql-java-tools:

    I first define a GraphQL Config like this:

    @Configuration
    public class GraphQLConfig {
        @Bean
        public Map executionStrategies() {
            Map executionStrategyMap = new HashMap<>();
            executionStrategyMap.put("queryExecutionStrategy", new AsyncTransactionalExecutionStrategy());
            return executionStrategyMap;
        }
    }
    

    Where AsyncTransactionalExecutionStrategy is defined like this:

    @Service
    public class AsyncTransactionalExecutionStrategy extends AsyncExecutionStrategy {
    
        @Override
        @Transactional
        public CompletableFuture execute(ExecutionContext executionContext, ExecutionStrategyParameters parameters) throws NonNullableFieldWasNullException {
            return super.execute(executionContext, parameters);
        }
    }
    

    This puts the whole execution of the query inside the same transaction. I don't know if this is the most optimal solution, and it also already has some drawbacks in regards to error handling, but you don't need to define a type resolver that way.

提交回复
热议问题