Got a crash in compilation using response-based (works in operation-based) codegen due to as I proba...

# apollo-kotlin

[Stylianos Gakis]

Got a crash in compilation using response-based (works in operation-based) codegen due to as I probably understand a deeeeply nested object due to a lot of … on fragments inside fragments and so on. Error code looks like this:
e: error while writing /Users/stylianosgakis/ProjectsKmm/EmbarkX/shared/build/tmp/kotlin-classes/debug/com/hedvig/giraffe/adapter/EmbarkStoryQuery_ResponseAdapter$Data$EmbarkStory$Passage$EmbarkAddressAutocompleteActionAction$AddressAutocompleteActionData$EmbarkApiGraphQLMutationApi$MutationData$EmbarkAPIGraphQLMultiActionVariableVariable$EmbarkAPIGraphQLGeneratedVariableVariable.class (Permission denied) and I have no idea what this is, just guessing it may have something to do with the name of the file being this big? Does the error ring any bells?

[Stylianos Gakis]

The repo is this, the query is this and I can share the schema as well if it’d make your life easier

[mbonnin]

Maybe the filename is too long. Can you try flattenModels.set(true)

[Stylianos Gakis]

Hmm yeah seems to work indeed. Changed the generated models quite a lot as it was to be expected.
How come this isn’t the default for response-based code generation?
Any gotchas I should know about this change? Any implications with the test builders for example, something else?

[mbonnin]

How come this isn’t the default for response-based code generation?

Because everything is flattened there's a high risk of nameclashes so you will have suffixed classes. You can also use aliases to "shorten" some paths if required. It's a tradeoff really

[Stylianos Gakis]

name-clashes of course. I can already see some generated files like “SubExpression22”, and “OtherVariable19". Ouch 💀

[Stylianos Gakis]

This probably speaks more about how our query/schema is defined, but in anyway this will probably be quite annoying to deal with hmm. Is this file name length limitation not something fixable in some other way to your knowledge?

[mbonnin]

Sadly I'm not sure there is a simple solution. You could run the codegen on a different filesystem but the fact that MacOS limits to 256 by default is annoying to say the least

[mbonnin]

TBH, this is one of the main reasons why operationBased is still the default. responseBased is a lot more involved

[mbonnin]

The other way to look at this is try to have the JVM use .class files that do not match the qualified name of the containing class

[mbonnin]

I haven't investigated the JVM spec to see if it's possible but that seems not easy (if even possible)

[Stylianos Gakis]

It is very unfortunate indeed!
All these potential workarounds definitely sound interesting but also absolutely non-trivial to solve 😕 What an unfortunate situation.

I will go with the flatten approach for now and see if this proves to be too annoying to use in code and simply fall back to operationBased if it does prove to be that way. I hope it doesn’t have to be that, as I really like what responseBased codegen brings to the table.

And oooonce again, thanks so much for helping me out with this one as well! I really do appreciate it!

[mbonnin]

Sure thing!