Breaking change from `4.2.7-SNAPSHOT` to `4.3.1` for repositories with abstract or interface entities

[JesusTheHun]

This repository method causes an issue with 4.3.1 but not with 4.2.7-SNAPSHOT :

@Query("#{#n1ql.selectEntity} USE KEYS $1")
List<BaseManageableEntity> findAllByIdIn(List<String> ids);

This method can return a variety of types of documents all extending the BaseManageableEntity abstract class.
With 4.2.7-SNAPSHOT the returned objects have the type of their inner class, A or B both extending BaseManageableEntity, the list carries the lower bound and is of type List<BaseManageableEntity>.
With 4.3.1 the returned method tries to deserialize the documents as instances of BaseManageableEntity causing an error, since BaseManageableEntity is an abstract class.

The behavior of 4.2.7-SNAPSHOT is the correct behavior imo, since it's easier and more natural to go in this direction than the other one.

[mikereiche]

There was a change to create objects that match the return type instead of the entity type of the repository - to handle methods that use projections to create other types of objects. Looking...

[mikereiche]

Hi - Can you provide an example of this?

[JesusTheHun]

This is a nice improvement but it should not break current behavior in this major release branch.

One solution could be to use the _class attribute if present and then cast into the return type, and if not present then use the return type.
This way you can avoid breaking both features.

[mikereiche]

use the _class attribute if present and then cast into the return type, and if not present then use the return type.

It's supposed to do that. That's the bug. In the change for matching the return type, projecting the _class (or typeKey) property was dropped. So it always fell back to the entity of the repository. The fix is simple. But obviously I need to add some test cases.

As a hack, adding a _class property to the BaseManageableEntity class will result in the _class property of the document being projected, and the converter being able to figure out what to instantiate.

protected String _class;

[JesusTheHun]

Hi - Can you provide an example of this?

Here is a close reproduction of my case :

Entities

public abstract class AuditedEntity implements Serializable {

    @Field("is_audited_entity")
    protected boolean isAuditedEntity = true; // we use this as a class hierarchy root identifier.

    @Id
    @GeneratedValue(strategy = UNIQUE, delimiter = ID_DELIMITER)
    protected String id;

    @Version
    @Field("revision")
    protected Long revision;

    @CreatedBy
    @Field("created_by")
    protected String createdById;

    @CreatedDate
    @Field("created_date")
    protected Instant createdDate = Instant.now();

    @LastModifiedBy
    @Field("last_modified_by")
    protected String lastModifiedById;

    @LastModifiedDate
    @Field("last_modified_date")
    protected Instant lastModifiedDate = Instant.now();

    public String getId() {
        return id;
    }

    public void setId(String id) {
        this.id = id;
    }

    public String getCreatedById() {
        return createdById;
    }

    public void setCreatedBy(Customer customer) {
        this.createdById = customer.getId();
    }

    public void setCreatedById(String createdBy) {
        this.createdById = createdBy;
    }

    public Instant getCreatedDate() {
        return createdDate;
    }

    public void setCreatedDate(Instant createdDate) {
        this.createdDate = createdDate;
    }

    public String getLastModifiedById() {
        return lastModifiedById;
    }

    public void setLastModifiedBy(Customer lastModifiedBy) {
        this.lastModifiedById = lastModifiedBy.getId();
    }

    public void setLastModifiedById(String lastModifiedById) {
        this.lastModifiedById = lastModifiedById;
    }

    public Instant getLastModifiedDate() {
        return lastModifiedDate;
    }

    public void setLastModifiedDate(Instant lastModifiedDate) {
        this.lastModifiedDate = lastModifiedDate;
    }

    public Long getRevision() {
        return revision;
    }

    public void setRevision(long revision) {
        this.revision = revision;
    }
}

@Document
@Data
class EntityA extends AuditedEntity {
    String specificPropOne;
}

@Document
@Data
class EntityB extends AuditedEntity {
    String specificPropTwo;
}

Repositories

public interface EntityARepository extends CouchbaseRepository<String, EntityA> {

}

public interface EntityBRepository extends CouchbaseRepository<String, EntityB> {

}

public interface AuditedEntityRepository extends Repository<String, AuditedEntity> {
    @Query("SELECT * FROM #{#n1ql.bucket} WHERE is_audited_entity = true")
    List<AuditedEntity> findAll();
}

Then you should be able to retrieve all AuditedEntity with the repo method. All objects being either EntityA or EntityB.
Does that respond to your request ?

[mikereiche]

That's good. I actually was able to reproduce with the Foo/BaseManageableEntity from issue 1312. The fix is to change this is the addition of typeField on the entity projection in StringBasedN1qlQueryParser. As soon as I make some test cases I'll merge the fix to both main and 4.3.x

String entity = "META(" + i(b) + ").id AS " + SELECT_ID + ", META(" + i(b) + ").cas AS " + SELECT_CAS + ", "+typeField;

[mikereiche]

btw - derived queries (those without an @query definition) on a repository for an abstract entity class and the default type (i.e. no @typealias) will never select any rows that have been saved by that repository because the _class = predicate will use the abstract class name, while the documents will have been saved with their concrete class name.