https://kotlinlang.org logo
Join Slack
Powered by
Another little point: <https://kotlinlang.slack.co...
# komapper
d
t
What would a property-based strategy look like in this context?
d
enum Foo(val value: Int) { Bar(2), Baz(3) }
I need the 
value
property... maybe 
@KomapperEnum("value")
?
t
Oh, that’s looks good. However, for compatibility we may need to do the following:
Copy code
@KomapperEnum(EnumType.FIRST_PARAM)
FIRST_PARAM means the first parameter of enum`s constructor.
d
I don't think I'd limit to first param if possible... you could have a second paramater to the annotation 
paramName
that default to an empty string and the EnumType.PARAM
That way if there are a few parameters, the user can choose which one to use.
If there's only one param, then maybe a user shouldn't even need to specify the name
t
I understand what you are saying, but I think the API you suggested is a bit confusing.
d
FIRST_PARAM
is certainly better than nothing, but would be a bit limiting if these were actual domain classes...
It certainly better than my current value class wrapper...
Copy code
@JvmInline
value class FooWrapper(val value: Int) {
    val status: Foo get() = Foo.values().first { it.value == value }
}

enum class Foo(val value: Int) {
    Baz(2), Baz2(3), Bar(4);
}
t
In your case, sealed class might be suitable instead of enum.
Copy code
abstract class Foo(val value: Int) {
    object Baz: Foo(2)
    object Baz2: Foo(3)
    object Bar: Foo(4)
}

class FooTypeConverter : DataTypeConverter<Foo, Int> {
    override val exteriorClass: KClass<Foo> = Foo::class
    override val interiorClass: KClass<Int> = Int::class

    override fun unwrap(exterior: Foo): Int {
        return exterior.value
    }

    override fun wrap(interior: Int): Foo {
        return when(interior) {
            2 -> Foo.Baz
            3 -> Foo.Baz2
            4 -> Foo.Baz
            else -> error("unknown: $interior")
        }
    }
}

@KomapperEntity
data class Person(@KomapperId val id: Int, val foo: Foo)
See also https://www.komapper.org/docs/reference/data-type/#data-type-conversion
d
And an adapter like that couldn't be written for an enum? (It's simpler than a sealed class in my head...)
Oh well, it seems to ignore my converter for my existing enum... even though I didn't annotate the field with Enum... it still uses the name of the enum and not the value property... @Toshihiro Nakamura
Funny though that Intellij says:
Is that the right place?
@Toshihiro Nakamura Even your example doesn't work (adapted for my use case...). It says it doesn't find the dataType
t
DataTypeConverter doesn’t support enum. So use sealed class instead.
Is that the right place?
Yes. But, is there an extra space at the end of 
org.komapper.core.spi.DataTypeConverter
?
d
no
message has been deleted
You mean at the end of the file name? Or white space in the file itself?
t
at the end of the file name.
d
🤒 How did you guess? I guess copy/pasting plays nice tricks... now it works. I wonder if my enum version also worked... I prefer keeping the value property the source of truth and avoid that 
when
in sealed class version
Nope... it still uses the 
name
property and ignores my DataTypeConverter 🙈
t
Komapper treats Enum specially to allow easy mapping. As a trade-off, Komapper cannot support DataTypeConverter for Enums.
d
Even w/o the 
@KomapperEnum
annotation... maybe just treat it special WITH the annotation? (which is what I would have expected...)
But in any case... if you would implement using properties for the interior value... it would cover this use case.
t
Komapper treats Enum specially even without annotation.
d
Yeah, and I guess it would be a not-backwards compatible change to require the annotation.
10 Views
Open in Slack
PreviousNext
Powered by