-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add perf feature-flag; ensure compatability with LaunchDarkly (LDv5) users #21534
Conversation
Airbyte Code Coverage
|
@Requires(missingProperty = CONFIG_LD_KEY) | ||
@Singleton | ||
fun ConfigFileClient(@Property(name = CONFIG_OSS_KEY) configPath: String): FeatureFlagClient { | ||
val path: Path? = if (configPath.isNotBlank()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Out of curiosity, Kotlin doesn't have a more succinct way to represent this type of if/else? Or, are you just avoiding using a ternary or elvis operator for stylistic/readability reasons?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Kotlin doesn't have a ternary operator, instead having an if/else
and when
expressions. The elvis operator only works when the left-hand side of the operator is null
. As the configPath
variables cannot be null (it's a String
not a String?
) I would have to convert it to a null in order to use a elvis operator.
Here I think it's a stylistic/readability choice.
Which one is easier to read?
if/else:
val path: Path? = if (configPath.isNotBlank()) {
Path.of(configPath)
} else {
null
}
when:
val path: Path? = when {
configPath.isNotBlank() -> Path.of(configPath)
else -> null
}
elvis (actually doesn't need an elvis as we want the null value)
val path: Path? = configPath.takeIf { it.isNotBlank() }?.let { Path.of(it) }
Having written these all out now, maybe I'll change this to use the when
statement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
builds on add perf feature-flag; ensure compatability with LaunchDarkly (LDv5) users #21534 add support for checking the PerfBackgroundJsonValidation feature-flag within the RecordSchemaValidator class I spent a lot of time with trying to get the Kotlin beans injectable into the java code. What should just work doesn't and it well documented on the Micronaut side as to what exactly is required (or at least I never found the documentation). After many attempts I and looking at the auto-generated kotlin Micronaut projects I landed on kapt being necessary in kotlin projects. Even this isn't entirely true. If the Kotlin project is defined with the following gradle setup, the beans will not be visible to java projects (and possibly other projects as well): plugins { kotlin("jvm") version "1.8.0" } dependencies { annotationProcessor(platform(libs.micronaut.bom)) annotationProcessor(libs.bundles.micronaut.annotation.processor) } But they will be visible with the following setup: plugins { kotlin("jvm") version "1.8.0" id("io.micronaut.minimal.application") version "3.7.0" } dependencies { annotationProcessor(platform(libs.micronaut.bom)) annotationProcessor(libs.bundles.micronaut.annotation.processor) } micronaut { version("3.8.2") } and also visible with the following setup: plugins { kotlin("jvm") version "1.8.0" kotlin("kapt") version "1.8.0" } dependencies { kapt(platform(libs.micronaut.bom)) kapt(libs.bundles.micronaut.annotation.processor) } I went with the kapt solution. It's worth noting that kapt is deprecated and is being replaced with kps in Micronaut 4 (this is a good thing). --------- Co-authored-by: Davin Chia <davinchia@gmail.com>
What
ConfigFileClient
to support passing in anull
config file pathnull
config is provided, the requested feature-flag default values will always be returnedFeatureFlagClient
easierMulti
contexts to work with LDv5Context
attributes are set correctly on the LaunchDarkly userperformance.backgroundJsonSchemaValidation
feature flagflags.yml
andFlags.kt
filesRecommended reading order
Flags.kt
flags.yml
Context.kt
Client.kt