Expected types in keyset for embeddables

[mickroll]

What types should i expect in the keyset returned by blaze persistence? The ones defined in the selected entity i guess: string column -> string in keyset. But what about embeddables?

I have the following Entity:

@Entity
public class ExampleEntity {
    @EmbeddedId
    private ExampleId id;

    private String firstName;

    @Embedded
    private Address address;

// constructors, getters, etc.
}

With this Id record (could also be a class, shouldn't matter):

@Embeddable
public record ExampleId(
        @Column(name = "id", updatable = false, nullable = false, columnDefinition = FieldDef.UUID_TYPE)
        @Basic
        @JdbcTypeCode(Types.CHAR)
        UUID id
        ) {
}

And this embeddable:

@Embeddable
public class Address {

    @Column
    private String street;

    @Column
    private String streetNumber;

// more fields; constructors, getters, etc.
}

Now, if i want to use keyset pagination with ExampleEntity, which types should i expect the returned keyset to contain?

• A: the same as defined in the Entity: [ExampleId, String, Address]
• B: their "exploded form": [UUID, String, String, String]

Example code:

public Demonstrator {
    @Inject CriteriaBuilderFactory cbf;
    @Inject EntityManager em;

    public void queryKeyset() {
        var query = cbf.create(em, ExampleEntity.class)
        final var paginatedQuery = query
                .page(0, 50)
                .withKeysetExtraction(true);
        final var foundRows = paginatedQuery.getResultList();
        
        final var keyset = foundRows.getKeysetPage().getHighest(); 
        // does keyset contain the types [ExampleId, String, Address] or their "exploded form" [UUID, String, String, String]?
    }
}

Why am i asking? Well, the behaviour seems to have changed from A to B with the update 1.6.9 -> 1.6.10, at least for the embedded id.

[beikov]

First of all, the keyset always only contains the state from the order by clause, so I guess your example just misses that?

I would argue that the keyset should contain exactly the representation by which you order by, so if you order by id and that has the type of an embeddable, the keyset should contain an embeddable instance. There were some changes in the embeddable expression splitting which might have caused this. I'll see if I can reproduce this, but it would be best if you could provide a reproducer application i.e. based on our maven quickstart archetypes.

In the meantime you can avoid uncertainty by using an order by clause that orders by individual components.

[mickroll]

Thanks for answering!

if you order by id and that has the type of an embeddable, the keyset should contain an embeddable instance

That would be my expectation, too.

Yes, i missed to add the order clause. Imagine one with all existing attributes of ExampleEntity for the sake of this example: id, firstName, address.*.

I'll see what i can do for a reproducer.

[mickroll]

@beikov Thanks for the hint to the quickstart archetypes, they were helpful for creating a reproducer in very short time. See https://github.com/mickroll/demonstrator/tree/blazebit-keyset-embedded-id

[beikov]

Thanks. I created #1834 to track this bug.