Another nice thing would be to have a `@KomapperPr...

# komapper

[dave08]

Another nice thing would be to have a @KomapperProjectionDef for when the model is declared in another module that shouldn't have a dependency to Komapper...

[dave08]

Oh, it already exists, it's just not in the docs 😊!

[Toshihiro Nakamura]

That’s right; I forgot to include it in the documentation.

[dave08]

Also, it's not mentioned if all the regular annotations apply (like KomapperColumn and KomapperIgnore), although I suppose they do (and that some don't...?)

[dave08]

Also, if there are some fields not in the ProjectionDef, are they considered ignored, or just default to what's declared in the original class?

[Toshihiro Nakamura]

Also, it’s not mentioned if all the regular annotations apply (like KomapperColumn and KomapperIgnore), although I suppose they do (and that some don’t...?)

Yes, all annotations are applied.

Also, if there are some fields not in the ProjectionDef, are they considered ignored, or just default to what’s declared in the original class?

What’s declared in the original class is used as the default.

[dave08]

So I don't really need to declare anything unless I need to add an annotation to one of the fields?

I wonder if being able to specify a strategy in the Def annotations as to this behaviour might simplify lots of them, since sometimes the original is the closest to what is needed, and in other times, the def might be closer (especially if there are many nullable fields in the original that need to be added on later in a decorator - like in my case in the current codebase that I need to refactor -- not that this is such good practice in the first place...).

[Toshihiro Nakamura]

So I don’t really need to declare anything unless I need to add an annotation to one of the fields?

No, you don’t.

Def is simply a class for specifying annotations on properties with the same names as those in the original class. I can’t quite picture a case where Def would be closer to what’s needed.

[dave08]

So I'll keep working on the migration, I might not find such a case... but the field order of the projection is kept, not the original, right (when using index based selectAsFoo)?

[Toshihiro Nakamura]

The field order of the class you want to instantiate is used.

[dave08]

Oh... I would have expected that I'm "overriding" the order too... so I guess I'll either have to modify the order in the select, or use ProjectionType.NAME
...