-
Notifications
You must be signed in to change notification settings - Fork 56
Retrieve all variations for a flag #161
Comments
Hi zacyang, Thanks for the suggestion. This is a low priority at the moment since we don't believe this feature request to be something that would be generally useful to most customers, but we'll keep this issue for future consideration. Ben |
It'd be easier to determine the best approach to this if the use case was clearer. This is something that could only be done when you have a live connection to LaunchDarkly - so, when you say "I needed a test", do you mean you would have a unit test or integration test that would actually connect to LD? Generally speaking it's not advisable to have CI tests like this rely on an external service. Or would this be something that is used in production by your application? It sounds like whichever context you want this in, you are already doing it now via your REST workaround so I'm sure you're already aware of the tradeoffs, but I'd just like to understand the intended usage better. |
@eli-darkly , thanks for getting back to me. Yes, we used a live connection to live LD in CI. Reason for this is, we have some feature switch based on variant. The value in the variants determine the behaviours of some particular actions, This is critical for us to guarantee the semantics (exactly once) of the events, therefor I need some test to make sure the variants are what we think it is before deploying to prod. And you are right, I've implemented the test based on the rest api you guys provided, just thought it would be nicer to have it thru client. |
(5.0 - #3) rename FeatureStore and UpdateProcessor
Hi @zacyang , After re-reading this ticket, I realize that we had a solution for you all along. We maintain a set of client libraries for interacting with LaunchDarkly's REST API. These clients are auto-generated from our OpenAPI spec. Most relevant here is api-client-java. Once you add api-client-java to your application you can use The reason for maintaining API client libraries separate from our SDKs (java-server-sdk and others) is to allow our SDKs to be as lightweight as possible. We generally only add functionality to the SDKs when the functionality is common and/or crucial to the flow of evaluating flag rulesets on behalf of users, sending events back to LaunchDarkly, and so forth. All other functionality should be accessed through our REST APIs by our auto-generated API client libraries. I'm going to close this ticket now. Cheers, |
I needed a test to verify that the constant default in the code base (java) is compatible with the given values (json array) on the server.
Describe the solution you'd like
Create a separate method in the client which can retrieve all the variations associated with a feature key.
Describe alternatives you've considered
Currently I have to use REST endpoint to request and parse the variations my self, as the LDClient is final.
The text was updated successfully, but these errors were encountered: