mapstruct / mapstruct/mapstruct
QOL improvement with @PrimaryMappingSource instead of explicit source declaration
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 7.7k
- Forks
- 1.1k
- PR merge metrics
- No merged PRs in 30d
Description
### Use case
Sometimes, a mapping needs to borrow a field from another table.
```java
@Mapping(target = "borrowed", source = "tblB.borrowed")
EntityA toEntity(TblA tblA, TblB tblB)
```
But if those tables have many similar fields, then we'll get lots of errors
```
error: Several possible source properties for target property "id"
error: Several possible source properties for target property "name"
error: Several possible source properties for target property "description"
error: Several possible source properties for target property "createdAtUtc"
error: Several possible source properties for target property "updatedAtUtc"
```
which can be resolved by manually specifying the source of every conflicting property
```java
@Mapping(target = "id", source = "tblA.id")
@Mapping(target = "id", source = "tblA.name")
@Mapping(target = "id", source = "tblA.description")
@Mapping(target = "id", source = "tblA.createdAtUtc")
@Mapping(target = "id", source = "tblA.updatedAtUtc")
@Mapping(target = "borrowed", source = "tblB.borrowed")
EntityA toEntity(TblA tblA, TblB tblB)
```
My proposal is a new annotation called something like `@PrimaryMappingSource` which would be used like this
```java
@Mapping(target = "borrowed", source = "tblB.borrowed")
EntityA toEntity(
@PrimaryMappingSource TblA tblA,
TblB tblB
)
```
Which would have the effect of defaulting to tblA when there is any ambiguity in the source for a target property. This is similar to the `@org.springframework.context.annotation.Primary` annotation, which they explain like this:
>Indicates that a bean should be given preference when multiple candidates are qualified to autowire a single-valued dependency. If exactly one 'primary' bean exists among the candidates, it will be the autowired value.
### Generated Code
The generated code would be the same as manually specifying the source of all those ambiguous properties
### Possible workarounds
_No response_
### MapStruct Version
_No response_
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
The issue names no source files, tests, or entry points. Start by locating MapStruct's ambiguous source-property resolution and annotation-processing tests, then compare existing parameter-annotation conventions. Done should include a supported primary-source annotation, coverage for ambiguous properties, and generated mappings equivalent to explicit source declarations.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- developer-experience, tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100