Do I really need to use `KomapperColumnOverride` for embedded fields? Or can I just annotate the emb...

# komapper

[dave08]

Do I really need to use KomapperColumnOverride for embedded fields? Or can I just annotate the embedded class with a regular KomapperColumn?

[Toshihiro Nakamura]

Yes, you do if you want to specify your column name. We don’t support KomapperColumn for embedded class properties. We believe that embedded classes should be free from Komapper’s annotations.

[dave08]

Why? It's all on the data layer anyways...

[dave08]

And for bigger embedded classes, it can get to be pretty messy to put all those annotations on that one field.

[dave08]

There could always be a @KomapperEmbeddedClass annotation or ``KomapperEmbeddedClassDef` that would automatically make it embedded into any class that has it as a field. On the data layer, that wouldn't make total sense?

[dave08]

Those that would want to avoid that could always use the override and embedded annotations...

[Toshihiro Nakamura]

In most cases, embedded classes are reused by multiple entities. In that case, it is easier to understand and flexible if the column names are specified on the entity class side.

[dave08]

Maybe, but I guess not in my case... and to have a string override is open to refactoring problems... if the override key would have been a KProperty, I guess it would solve the refactoring problem -- but having them straight on the embedded class would solve both.

[Toshihiro Nakamura]

If @KomapperColumn is allowed in embedded classes, users will mistakenly think that other annotations such as @KomapperVersion are also available in embedded classes. However, we would like to avoid that.
The refactoring problem may be solved by using constants (const val) for column names.

[dave08]

The refactoring problem may be solved by using constants (const val) for column names.

Not really, since if once renames class Foo(val prop1: String) to prop2 the constant val won't automatically change itself... I don't think even Intellij's refactoring would know that...

[dave08]

I guess it would crash the ksp stage of the build though, since an unexisting property is trying to be overrided

[dave08]

users will mistakenly think that other annotations such as @KomapperVersion are also available in embedded classes. However, we would like to avoid that.

Yeah, that would probably be one thing that's confusing here.

[Toshihiro Nakamura]

The refactoring problem may be solved by using constants (const val) for column names.

The following code represents what I am trying to say:

// embedded value
data class Money(val amount: BigDecimal, val currency: String)

// column name for Money.amount
const val amount = "AMT"

@KomapperEntity
data class Employee(
    @KomapperId
    val id: Int,
    @KomapperColumnOverride("amount", KomapperColumn(amount)) // use the above constant
    val salary: Money
)

@KomapperEntity
data class Person(
    @KomapperId
    val id: Int,
    @KomapperColumnOverride("amount", KomapperColumn(amount)) // use the above constant
    val salary: Money
)

[dave08]

Yeah, but the @KomapperColumnOverride("amount"... "amount" could have been @KomapperColumnOverride(Money::amount,... ? I'm not sure if that's valid in an annotation, but otherwise, if the property is renamed, then it would break.

[dave08]

I guess it would get picked up by your ksp parser though

[Toshihiro Nakamura]

@KomapperColumnOverride(Money::amount,… is invalid annotation.

if the property is renamed, then it would break.

I guess it would get picked up by your ksp parser though

Yes. Komapper`s KSP processor detects that break at compile-time.