A modern programming language that makes developers happier.

kotlinlang

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

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.

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

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

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?

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

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.

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.

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.

&gt; 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...

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

&gt; 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.

&gt; 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
)```

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.

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

`@KomapperColumnOverride(Money::amount,…` is invalid annotation.
&gt; if the property is renamed, then it would break.
&gt; I guess it would get picked up by your ksp parser though
Yes. Komapper`s KSP processor detects that break at compile-time.