Jan Martiska
Jan Martiska
The problem (or part of it) seems to be that the `MultiDataFetcher` shares a single instance of `DataFetcherResult.Builder` for all its produced items, so when the processing of one item...
@phillip-kruger I'd like to have a look into this if you don't mind
This could also use writing some Quarkus-side integration test coverage as part of doing the review (well, if possible - because running a real integration test seems to require a...
I'd suggest rebasing, as there is a conflict anyway ;) and pushing again
I'll create a 1.9.x branch with this that will target Quarkus 2.15, which is due some time in December or January, so we will have enough time to polish it....
I suppose users should be able to cover their transaction needs by applying the `@javax.transaction.Transactional` annotations (or use an injected `UserTransaction` programmatically) as necessary on the beans that handle mutations,...
> When one request contains multiple mutations, I'd expect them to run in a single transaction Why? Is that really necessary? If such behavior is necessary in a particular application,...
> If a client updates three things in one request, she will assume that they all worked or none. If I imagine us doing it this way, I can imagine...
Hey @phillip-kruger mind if I take this? I'm looking for some no-brainer tasks right now :)
Some modules still don't have it, like the client, client generator, schema builder, schema model, gradle and maven plugins... I'm not sure if it's appropriate to i18n all of them.