Does panache generate getters and setter?

[agreedSkiing]

Hi,
We have been trying to use the repository pattern for Panache in our new project and we don't want to write our own getters and setters so we extended our MappedSuperClass with PanacheEntityBase to make all our entities have the correct getters and setters generated, but none are generated... Is this the correct behaviour?

We have also tried on the side to just extend a single Entity where we use UUID with PanacheEntityBase and as the rest of our entities kept all the internal variables either package scope or private, with no luck their either

We are using Quarkus 2.13.3.Final.

Link to the tip https://quarkus.io/guides/hibernate-orm-panache#solution-2-using-the-repository-pattern

[quarkus-bot[bot]]

/cc @FroMage, @loicmathieu

[loicmathieu]

@agreedSkiing getters/setters generation are done when building your application, you just use public fields in the code and we generates bytecodes to replace their usage with getters and setters. We do have code to test this. As it done at build time (via mvn package for eg) you will not notice it.

[maxandersen]

It is not generated in source - just done at bytecode level.

[agreedSkiing]

Okay, so why replace public access with getters and setter, and what happens with boolean methods? Does it generate isBoolean?

Also, why then have repository pattern and active record pattern in the same code? This feels like it breaks the repository pattern and is bound to create confusion in a development team if the dev team follow the tip on the page guide if they start to mix repository pattern and active record pattern. Might it not be better to recommend Lombok instead, even though Lombok might be controversial for some people?

[maxandersen]

Whdym repository and active is in the same code ? You can use either - up to you if you mix and match?

Lombok - what advantage would that bring user besides you'll need to wait for Lombok generation ?

[loicmathieu]

why replace public access with getters and setter

Because it's mandatory for JPA. By the way, Hibernate ORM also did this, also via bytecode enhancement.

Does it generate isBoolean?

Yes.

why then have repository pattern and active record pattern in the same code?

For convenience purpose, if you want to use the repository pattern and still have you getter/setters generated for you. It's a design choice you can made.

This feels like it breaks the repository pattern and is bound to create confusion in a development team if the dev team follow the tip on the page guide if they start to mix repository pattern and active record pattern.

If it didn't feel good for you, this design choice may not be OK for you and your team ;). Again, it's a choice you have to make, we just offer the possibility to.

Might it not be better to recommend Lombok instead, even though Lombok might be controversial for some people?

As you said, Lombok may be controversial, I have an opinion on Lombok but I prefere not to start a controverse here ;)

[agreedSkiing]

@maxandersen

Whdym repository and active is in the same code ? You can use either - up to you if you mix and match?

For us it was the idea of skipping the creation of getters and setters completely, and I got no problem with mixing and maxing just that the code base suddenly implements two patterns where one can break our code structure (a structure where we want to have all our database call code for a given table in one place/layer).

Lombok - what advantage would that bring user besides you'll need to wait for Lombok generation ?

For us it currently brings the need to not write repetitive code and most of our team already uses Lombok plugins since an earlier migration project helps with the Lombok jar. Lombok might not bring any advantages since it hides code implementation behind handy annotations on a class and the team I’m part of has agreed to not use the @DaTa since it was used everywhere on the migration project, that includes entity objects. This kind of agreement could also be used for the mixing of repository and active pattering and might also be enforceable the same way as our @DaTa agreement with a code scanner.

[maxandersen]

For us it was the idea of skipping the creation of getters and setters completely, and I got no problem with mixing and maxing just that the code base suddenly implements two patterns where one can break our code structure (a structure where we want to have all our database call code for a given table in one place/layer).

okey, so your concern is that if you extend PanacheEntity you get both the automatic get/setters + activerecord query method?

Alright, I can see how that can be problematic for some. How about you write a blog or guide giving example on how if you have this concern you can use things like Lombok?

Contributing such documentation/tips and publishing it to the Quarkus ecosystem would be great.

[agreedSkiing]

Hi again and sorry for the necro of this Q&A but,

I will probably try to discourage my team from using Lombok for getters and setters. Why? Well, I did some “investigation” (more or less experimenting), after i noticed a thing in the guide about mocking repository pattern, where the entity has public variables and isn’t using a panache entity, and after the comment about Hibernate ORM doing the same from @loicmathieu.

Your comment @loicmathieu and the guide section about mocking made me question the previous tip in the guide about using panache entitybase to generate getters and setters (the mocking example was the biggest benefactor for me to question the tip). So I changed some entities to use public variables instead and ran the @QuarkusTest we have that do inserts and reads with those entities against a postgres testcontainer with the panache repository style and all our @QuarkusIntegrationTest which currently can only access two read endpoints that get the entities plain without joining them against each other and to my surprise it worked. Why does it work, is the Hibernate ORM that changes the public accessors to getter and setter? I don't know, but it works though. Below are the enteties that I modified on a local branch and ran our test against and yes, the names and packages might not sense but I made the name changes just now to share some of the code.

Public access entities

Mapped Super Class

package com.company.project.common.entity;

import java.time.Instant;
import java.util.UUID;
import javax.persistence.Column;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;
import javax.persistence.MappedSuperclass;
import javax.persistence.PrePersist;
import javax.persistence.PreUpdate;
import javax.persistence.Version;
import lombok.NoArgsConstructor;
import org.hibernate.annotations.GenericGenerator;

@NoArgsConstructor
@MappedSuperclass
public abstract class AbstractEntity {

    public AbstractEntity(String createdBy, String modifiedBy, int version) {
        this.createdBy = createdBy;
        this.modifiedBy = modifiedBy;
        this.version = version;
    }

    @Id
    @GeneratedValue(generator = "resource-uuid")
    @GenericGenerator(name = "resource-uuid", strategy = "org.hibernate.id.UUIDGenerator")
    @Column(name = "resource_id", nullable = false, updatable = false)
    public UUID resourceIdentifier;

    @Column(name = "created_at", nullable = false, updatable = false)
    public Instant createdAt;

    @Column(name = "modified_at")
    public Instant modifiedAt;

    @Column(name = "created_by")
    public String createdBy;

    @Column(name = "modified_by")
    public String modifiedBy;

    @Version
    @Column(name = "version", nullable = false)
    public int version; // For optimistic locking

    @PrePersist
    protected void onCreate() {
        createdAt = Instant.now();
        modifiedAt = null;
    }

    @PreUpdate
    protected void onModify() {
        modifiedAt = Instant.now();
    }
}

Parent

package com.company.project.logistics.db.entity;

import java.util.Set;
import javax.persistence.CascadeType;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.EnumType;
import javax.persistence.Enumerated;
import javax.persistence.FetchType;
import javax.persistence.OneToMany;
import javax.persistence.Table;
import lombok.NoArgsConstructor;
import com.company.project.common.entity.AbstractEntity;

@NoArgsConstructor
@Entity
@Table(name = "crate")
public class Crate extends AbstractEntity {

    public Crate(String createdBy, String modifiedBy, int version, String crateIdentifier,
            crateType crateType, crateStatus crateStatus, String crateVersion, String name,
            String alternateName, String description, String maintainer, String source, Set<item> items) {
        super(createdBy, modifiedBy, version);
        this.crateIdentifier = crateIdentifier;
        this.crateType = crateType;
        this.crateStatus = crateStatus;
        this.crateVersion = crateVersion;
        this.name = name;
        this.alternateName = alternateName;
        this.description = description;
        this.maintainer = maintainer;
        this.source = source;
        this.items = items;
    }

    @Column(name = "system_identifier", nullable = false)
    public String crateIdentifier;

    @Enumerated(EnumType.STRING)
    @Column(name = "system_type")
    public CrateType crateType;

    @Enumerated(EnumType.STRING)
    @Column(name = "system_status")
    public CrateStatus crateStatus;

    @Column(name = "system_version")
    public String crateVersion;

    @Column(name = "system_name")
    public String name;

    @Column(name = "alternateName")
    public String alternateName;

    @Column(name = "description")
    public String description;

    @Column(name = "maintainer")
    public String maintainer;

    @Column(name = "system_source")
    public String source;

    @OneToMany(fetch = FetchType.EAGER, cascade = CascadeType.ALL, mappedBy = "crate")
    public Set<Item> items;
}

Enumclass 1

package com.company.project.logistics.db.entity;

public enum CrateType {
    PLASTIC, WOODEN, METAL, BOTTLE, CONTAINER, PET
}

Enumclass 2

package com.company.project.logistics.db.entity;

public enum CrateStatus {
    FILLING, FULL, EMPTY, EMPTYING, TRANSPORTING, DELIVERED
}

Child entity

package com.company.project.logistics.db.entity;

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.FetchType;
import javax.persistence.JoinColumn;
import javax.persistence.ManyToOne;
import javax.persistence.Table;

import lombok.NoArgsConstructor;
import com.company.project.common.entity.AbstractEntity;

@NoArgsConstructor
@Entity
@Table(name = "item")
public class Item extends AbstractEntity {

    public Item(String createdBy, String modifiedBy, int version, String itemIdentifier, String displayName,
            String originalText, String additionalInfo) {
        super(createdBy, modifiedBy, version);
        this.itemIdentifier = itemIdentifier;
        this.displayName = displayName;
        this.originalText = originalText;
        this.additionalInfo = additionalInfo;
    }

    @Column(name = "item")
    public String itemIdentifier;

    @Column(name = "display_name")
    public String displayName;

    @Column(name = "original_text")
    public String originalText;

    @Column(name = "additional_info")
    public String additionalInfo;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "crate_resource_id")
    public Crate crate;
}

Conclusions

I'm now trying to convert the whole team to use public accesses instead of using Lombok for the previously mentioned getters and setters, but I will see how that goes. This find made me kinda happy though, since I haven’t found it documented anywhere.

Now we are instead running into another problem regarding reactive queries and join fetch in HQL or programmatic doing the join fetch but that is more to our inexperience with reactive hibernate + Panache and if we get stuck on that problem I might create another Q&A instead to know the best practices.

P.S. We are using lombok for some of the nice to have annotation as seen in the item blocks.

P.S.S. Also another thing i noticed whilst I was “investigating” public access is that you can define a variable with a @manytoone relation and @joincolumn(name=”fk_parent_id”, updatable=false,insertable=false) and have a public access variable with a @column(name=”fk_parent_id”) in the same entity without having a collision like C# entity framework (I like how C# entity framework allows a relation mapping and foreign key of the relation to exist in an entity like their relation example which makes it obvious for me which entity contains the foregin key form the item alone, I still have problems to understand which is the parent with the @onetomany and @manytoone annotations), though i haven’t tried joining them with a JOIN FETCH or doing so programmatically).

Child entity with obvious foregin key

package com.company.project.logistics.db.entity;

import java.util.UUID;

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.FetchType;
import javax.persistence.JoinColumn;
import javax.persistence.ManyToOne;
import javax.persistence.Table;

import lombok.NoArgsConstructor;
import com.company.project.common.entity.AbstractEntity;

@NoArgsConstructor
@Entity
@Table(name = "item")
public class Item extends AbstractEntity {

    public Item(String createdBy, String modifiedBy, int version, String itemIdentifier, String displayName,
            String originalText, String additionalInfo) {
        super(createdBy, modifiedBy, version);
        this.itemIdentifier = itemIdentifier;
        this.displayName = displayName;
        this.originalText = originalText;
        this.additionalInfo = additionalInfo;
    }

    @Column(name = "item")
    public String itemIdentifier;

    @Column(name = "display_name")
    public String displayName;

    @Column(name = "original_text")
    public String originalText;

    @Column(name = "additional_info")
    public String additionalInfo;

    @Column(name = "crate_resource_id")
    public UUID crateResourceId;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "crate_resource_id", insertable = false, updatable = false)
    public Crate crate;
}