Bug in the AP for Implementations and the EV validation

[EugenMayer]

We are trying to implement DTOs as a based for EntityViews for different reasons

• be able to use the DTOs in non JPA context like WebVMC non JPA tests,
• other serialize / deserialize cases (e.g. a DGS alternative, but also others)
• Sharing transport layer specs with other Microservices without requiring them to be forced to have an JPA context.
• reduce the amount of manual code / errors when writing entityViews. Instead of manually writing a getter and setter, simply use Data and just use the list of fields for the entity as copy&paste.

For this, we do the following

Entity

class AppleEntity {
  @Id
  @GeneratedValue(strategy = GenerationType.IDENTITY)
  private Long id;
  private String name;
  private String type;
}

IdView

@Data
public interface AppleIdView {
    @IdMapper
    Long id;
}

Create / Update DTOs

@Data
public class AppleUpdateDTO implements AppleIdView {
    Long id;
    String name;
}

@Data
public class AppleCreateDTO extends AppleUpdateDTO{
    String type;    
}

Now our create/update views

@EntityView(AppleEntity.class)
@CreatableEntityView
abstract public class AppleCreateView extends AppleCreateDTO {
}

@EntityView(AppleEntity.class)
@UpdatableEntityView
abstract public class AppleUpdateView extends AppleUpdateDTO {
}

The Problem with the above would be, that the EVM scanner will now not detect the getter/setter at all or just the IdMapper annotation (we cannot tell)` - this is one bug / we expected to work. It should most probably not matter if the getter/setter are implemented or abstract (which AFAIU might be issue here).

To try to work around this issue we did

@EntityView(AppleEntity.class)
@CreatableEntityView
abstract public class AppleCreateView extends AppleCreateDTO {
    public AppleCreateView(
        @Mapping("id") Long id,
        @Mapping("name") String name,
        @Mapping("type") String type
    ) {
        super(id, name, type);
    }
}

The problem now is, that the AP that generates the AppleCreateViewImpl will fail to generate the constructor for the above. it will add the following constructor to the Impl

    public AppleCreateViewImple(
        Long id,
        Long id,
        String name,
        String type
    ) {
        ..
    }

I assume that the ID is always added as the default first parameter, no matter if it is already present. This means, the workaround cannot be compiled, while the one without Mapping will not validate.

We used the docs

• https://persistence.blazebit.com/documentation/1.4/entity-view/manual/en_US/index.html#map-external-data-model-with-view-constructor
  • https://persistence.blazebit.com/documentation/1.4/entity-view/manual/en_US/index.html#anchor-named-constructor

  • Could we discuss the vision / intend here. Thank you!

[EugenMayer]

We should try to use @IdMapping and not @Mapping

@EntityView(AppleEntity.class)
@CreatableEntityView
abstract public class AppleCreateView extends AppleCreateDTO {
    public AppleCreateView(
        @IdMapping("id") Long id,
        @Mapping("name") String name,
        @Mapping("type") String type
    ) {
        super(id, name, type);
    }
}

to see if the *Impl is generated properly.