https://kotlinlang.org logo
Join Slack
Powered by
```override fun resolveTypename(context: FakeResol...
# apollo-kotlin
m
Copy code
override fun resolveTypename(context: FakeResolverContext): String {
  val rawType = context.mergedField.type.rawType()

  // XXX: Cache this computation
  val possibleTypes = possibleTypes(allTypes, rawType)
  val index = context.id.hashCode().mod(possibleTypes.size)
  return possibleTypes[index].name
}
Is throwing 
java.lang.ArithmeticException: / by zero
for some data builders im trying to use in tests.
Is this an issue within my schema/queries or an oversight on the impl?
m
Guessing this is the 
modulo
throwing?
Can you dump 
rawType
there? Is it a composite type (object/interface/union)?
m
yep possible types is 0 evidently, jsut trying to uidnerstand why
The type is CustomerType which is a framgent
and this is how Im building the data builder
Copy code
workOrder = WorkOrderInfoImpl.Data(KrakenFieldFakeResolver()) {
    buildCustomWorkOrderType {
        id = "J_3443"
        customer = buildGBRCustomerType {

            name = "Jhon"
            phone = "442355"
            extension = "+54"
            psrData = listOf(
                buildPSRCustomerType {
                    summary = "summary"
                    internalCode = "internalCode"
                    gasPsrCode = "gasPsrCode"
                    electricityPsrCode = "electricityPsrCode"
                    expiryDate = LocalDate.parse("2021-10-10")
                },
            )

        }
m
The type is CustomerType which is a framgent
I’m guessing 
CustomerType
is more of an interface?
And 
GBRCustomerType
a concrete type?
type GBRCustomerType implements CustomerType
?
m
Indeed
Copy code
fragment customerType on CustomerType {
        id
        accountNumber
        name
        phone
        extension
        email
        familyName
        givenName
        ... on GBRCustomerType {
            psrData {
                summary
                internalCode
                gasPsrCode
                electricityPsrCode
                expiryDate
            }
        }
}
thats the fragment
m
So the question would be how come 
possibleTypes(allTypes, "CustomerType")
returns empty 🤔
Can you test that in isolation? What does 
__Schema.possibleTypes(CustomerType.type)
return?
m
sure thing
ah lovely empty list 😄
m
Alright so at least this part is “consistent” 😅
Does 
__Schema.all
contain 
GBRCustomerType
?
Might be an issue in how we track the used types
m
Interestingly enough, not only it does not contains GBRCustomerType, but it onl contains three types in total ( none related to Custoemr type)
this is the app module, and the schema is on the network module
am I misisng some config to always generate models or osmething?
m
Sounds like you’re missing the 
apolloMetadata()
dependency to reuse the network module schema
m
Oh I got that
m
Interesting. And it still generates a 
__Schema
class in your app module?
Theorically there should be only one 
__Schema
class in your whole repository
m
Copy code
apolloMetadata(project(":network"))
👍 1
yup it was there
ANd I believe the __Schema object its the one form netowk as the types in 
all
are from that module
( one mutation that lives there and the result of
Copy code
alwaysGenerateTypesMatching = listOf("APIErrorCode")
so maybe is a missconfig on the app module?
the CustomerType is only used by mutaitons/queires on the app module
not in network
m
Sounds like this is the issue. The network module doesn’t know about the types used in the app module.
think smart 1
There might be a solution, let me check
Besides 
alwaysGenerateTypesMatching.set(listOf(".*"))
which will always work at the expense of generating everything
Can you try in your network module:
Copy code
dependencies {
  apolloUsedCoordinates(project(":app"))
}
?
m
sure thing
nvm
m
top level dependencies
😅 1
m
hmm same results, and same amount CompiledNamedType on the _SchemmaFIle
m
Ah looks like you also need 
apolloSchema
in your app module
Copy code
// But also from the schema so as not to create a circular dependency
  apolloSchema(project(":schema"))
(apologies it's been a long time and this setup has changed quite a bunch in v4, see v4 doc)
m
cool, justneeding to apply some changes now that more models are being generated
but thats a good sign Id say
If I understood correctly this would create any model references in teh queries, mutation used by ( in my case) the app module
?
m
Yep • app retrieves 
schema.graphqls
using 
apolloSchema()
• app parses queries and generates 
usedCoordinates.json
(or so, not 100% sure about the naming) • network retrieves 
usedCoordinates.json
using 
apolloUsedCoordinates()
• networks generates 
__Schema.kt
, 
CustomerType.kt
, etc... • app retrieves the existing generated files from 
apolloMetadata()
and generates 
Operation1.kt
, 
Fragment1.kt
, etc...
It's a bit convoluted but this is just how Gradle works. If you don't care about project isolation, v4 has easier APIs
Also all in all, 
alwaysGenerateTypesMatching.set(listOf(".*"))
might be good enough or maybe even better than trying to auto detect
m
yup altho not sure if we want to generate aaal models we do ahve a fairly big schema
gonna try this and then hopefully change once we migrate
to v4
thansk!
m
Sure thing!
m
Right that deffo fix that issue. I m seeing some other oddity butthats enough for today
thanks for the time!
Open in Slack
PreviousNext
Powered by