it doesnt seem to like the multi layer breakdown h...

# apollo-kotlin

[Jeremie]

it doesnt seem to like the multi layer breakdown here, so if i just have this instead it compiles:

fragment ThreeLayerBreakdown on AbstractBreakdown {
    ...TokenBreakdownV3Fragment
}

[mbonnin]

Any chance you can share your schema and queries?

[mbonnin]

You can mp them if that's easier

[mbonnin]

(or use https://github.com/graphql-java/graphql-anonymizer)

[Jeremie]

what does mp mean

[Jeremie]

http://pastie.org/p/0MOEG0htSH915YtjZADJCa

[Jeremie]

so at the very bottom, it doesnt like the second level sub object

[Jeremie]

so if i remove that one it works

[mbonnin]

what does mp mean

Not sure... I guess I meant pm (private message) 😅 . sorry!

[Jeremie]

fragment ThreeLayerBreakdown on AbstractBreakdown {
    ...TokenBreakdownV3Fragment
    breakdown {
        ...TokenBreakdownV3Fragment
    }
}

works but not with an extra layer, but its a recursive object (which could go on infinitely but in this case we are happy with three layers

[mbonnin]

http://pastie.org/p/0MOEG0htSH915YtjZADJCa

Thanks for this. Would you have the matching schema.[json|graphqls] ?

[Jeremie]

ill pm you that 🙂

[mbonnin]

For the record, and anyone following that thread, the issue ended up being exponential blowup of the generated code due to many nested fragments. (basically this issue)

[mbonnin]

The code becomes so large that the compiler doesn't compile it anymore 😅

[mbonnin]

I'll put some monitoring/errors in the codegen so that we can report these cases more accurately

[mbonnin]

The solution is to use operationBased codegen when some queries use a lot of nested fragments. I've looked at this from every angle but I don't think it's possible to have both "direct access syntax" (skipping the fragments accessors) and not generate all possible response shapes

[Yang]

Does flattenModels.set(true) help?

[Jeremie]

Im already commited to operations based but I was curious about flatenModels, it avoids the crash, but gradle seems to hang indefinitely.

[mbonnin]

flattenModels.set(true) should not change the amount of code generated. The difference is that classes will all be at the first level instead of being nested. Maybe that's slightly easier for the compiler but that is still huge classes to compile