#dynamic dagql enums

1 messages · Page 1 of 1 (latest)

wooden pelican
#

taking a look! I think there's an interface you can implement here, just have to jog my memory

hollow vale
#

I implemented the typed interface but I'm not sure I did it the right way

#

Because it needs to infer T

wooden pelican
#

so like, in core:

type ModuleEnumValue string

// implement dagql.Input for ModuleEnumValue
hollow vale
#

So my EnumValueTypeDef should implement the interface? But how do I register the actual name of the enum?

wooden pelican
#

ah i see, yeah because it's coded to ~string you can't really include a dynamic type name

hollow vale
#

Yeah

#

In my case, I need to register the typename and then its values

#

I could also just create a new implementation of your dagql.Enum that isn't generic and take name + values as parameter so I can code the install properly

#

But I'm not sure it's the right way either

wooden pelican
#

maybe we should just change EnumValue to this?:

type EnumValue interface {
    Input
    String() string
}

so String() string instead of ~string

#

oh, but that still won't work well because the implementation depends on using the zero-value to get the type definition

#

yeah, seems like you need a Dynamic version of EnumValues, sort of like all the other DynamicFoos

hollow vale
#

Okay

wooden pelican
hollow vale
#

Can I assign it as a scalar after?

wooden pelican
#

sorry not sure what you mean thinkies

hollow vale
#

Or I also need to update the server to handle the enum in a specific way?

wooden pelican
#

oh, yeah you can just call srv.InstallScalar

#

that function probably should do that too, instead of reaching into the private field without a lock, don't remember if there's a special reason. might be cruft

hollow vale
#

Okay, I'm gonna try to implement it then

hollow vale
#

@wooden pelican I think I did something wrong in my implementation because the codegen is timing out, but I don't know what, I think it's related to DecodeInput & Decoder, but I kept the same logic as in other implementation so I don't really know :/

#

The feature is pretty tricky, sorry to disturb you 😦

#

Good news is that I'm able to reproduce the issue with dagger call --source=. test custom --run="TestTypeDefConversions" so it's pretty easy to verify if something's wrong

wooden pelican
#

sorry, will follow up on this soon! still focusing on OTel stuff which takes a lot of context 😅

hollow vale
#

Yeah sure no worry, I'm about to go to bed, feel free to leaves comments on my PR so I can continue tomorrow

#

I'm 100% I failed something, however I cannot spot what and it's pretty hard to find the issue since we implement a lot of interface + nesting them.

I'm thinking about writing a small doc after the enum support is shipped to document how to implement a new type/concept in the Dagger API

hollow vale
#

Ok I think I solved the timeout issue, I was able to regenerate clients with new enums methods, I can work on the registration then the calls

wooden pelican
#

oh nice!