Table of Contents
@Entity xor
@Embeddable@Id (not using
@IdClass or
@EmbeddedId)@GeneratedType for the
Id@NamedNativeQuery)The intent of JPA Objects is to allow you to exploit the knowledge you (may already) have of JPA to set up persistence for a Naked Objects applications. As such, most of the annotations of JPA can be used "in the regular way". That said, JPA Objects does not support a number of annotations, either:
by design, to enforce "best practice" for domain-driven applications;
by necessity, because Naked Objects itself does not support the annotation;
by happenstance; because JPA Objects implementation happens not to (though it could in the future).
Those in the first category are enforced through validation provided
by the metamodel (provided by an implementation of Naked Objects'
org.nakedobjects.metamodel.specloader.validator.MetaModelValidator
interface).
This chapter describes these restrictions.
Most domain classes will be annotated either as
@Entity or, if an aggregated object, then as
@Embeddable. The principle exceptions to this
will be classes that factor out common properties (see Section 8.5, “Common Properties
(@MappedSuperclass)”) and also value types (see Chapter 6, Supporting Custom Value Types).
It doesn't make sense for a domain class to be annotated using
both @Entity and
@Embeddable. JPA Objects'
metamodel validator will therefore reject any domain model (that is,
Naked Objects will fail to boot) where a domain class is annotated with
both.
JPA Objects also ensures that at least one
classes is loaded annotated with @Entity.