Evaluation Context Handling about go-sdk HOT 10 CLOSED

@james-milligan I think we should do this, yep! Go for it.

from go-sdk.

@toddbaert @beeme1mr @skyerus @davejohnston

from go-sdk.

If we flatten the structure into map[string]interface{} by inserting the rest of EvaluationContext's fields (currently just TargetingKey into the map we run into the issue that providers would need to look up the key from the sdk (e.g. targetingKey vs targeting-key) which is undesirable.

from go-sdk.

According to the spec, the targeting key is optional.

https://github.com/open-feature/spec/blob/main/specification/sections/03-evaluation-context.md#requirement-311

It's just a named property so we can properly map it to providers that required a unique identifier.

from go-sdk.

I feel like option two would be bring us closer to other SDKs.

from go-sdk.

I feel like option two would be bring us closer to other SDKs.

Agreed. I think this is also how flagd understands the evaluation context (as a flat object, please confirm @james-milligan ), which will bring those interfaces closer together. As mentioned before, I'd like flagd to eventually use the provider interface from the golang SDK, if reasonable.

from go-sdk.

That is correct, flagd expects a map[string]interface{}

I also agree that option 2 will be the cleanest approach for this

from go-sdk.

@james-milligan are there any next steps here or can we close the issue?

from go-sdk.

as of yet the changes haven't been implemented, im happy to assign this to myself and implement the changes, provided that is ok with @toddbaert
(if we still feel like this is a worthwhile change)

from go-sdk.

I've opened up a draft PR for this. I've opted to not introduce another type to wrap the map[string]interface{} to reduce confusion, but as the flattened context is returned by a function this would be very simple to implement.

from go-sdk.