jpa-entity

JPA Entity — Scaffold

Generate an entity that is born compliant with ruleset.json. The point: if the code is correct from the start, jpa-optimistic-lock, jpa-entity-equals, and friends never need to fire.

Step 1 — Detect project conventions (do not assume)

Read before generating:

• Base class / auditing: look for a @MappedSuperclass (e.g. BaseEntity, AuditableEntity) and AuditingEntityListener / @EnableJpaAuditing. If present, extend it instead of re-declaring id/audit fields.
• Id strategy: match the codebase — GenerationType.IDENTITY (Postgres/MySQL serial) vs assigned UUID. Default IDENTITY for numeric, or UUID if entities use it.
• Package + path: mirror an existing entity's package (e.g. …​.domain / …​.model / …​.entity). Write to the matching src/main/java/... path.
• Lombok: if the project uses Lombok, use @Getter/@Setter; otherwise write explicit accessors.
• Soft-delete: if other entities use a deleted/deletedAt column or @SQLDelete, offer the same; otherwise skip.

Step 2 — Generate (the non-negotiable invariants)

Every generated entity MUST have:

1. @Version field for optimistic locking.
2. equals/hashCode based on a stable business key or an assigned UUID — never the generated @Id (null pre-persist, breaks Set/Map membership).
3. Audit fields via the project's base class, or @CreatedDate/@LastModifiedDate if auditing is enabled and there's no base class.
4. Jakarta imports (jakarta.persistence.*), Spring Boot 3.x.

Use assets/jpa-entity.java.tmpl as the shape; fill {{PACKAGE}}, {{ENTITY}}, {{TABLE}}, {{FIELDS}}, {{ID_STRATEGY}}. The template carries a uid UUID business key (used by equals/hashCode) and @CreatedDate/@LastModifiedDate audit fields. If extending a base class, drop the id/version/audit fields it already provides (but ensure @Version exists somewhere in the hierarchy — if the base lacks it, keep it on the entity).