jakartaee / persistence

https://jakartaee.github.io/persistence/
Other
206 stars 59 forks source link

Section 4.4.4 does not have definitions of the entity/embeddable classes used in the example #308

Closed dazey3 closed 2 years ago

dazey3 commented 3 years ago

Section 4.4.4 defines two queries that it states are "equivalent":

In the following example, contactInfo denotes an embeddable class consisting of an address and set of phones. Phone is an entity.

    SELECT p.vendor FROM Employee e JOIN e.contactInfo.phones p WHERE e.contactInfo.address.zipcode = '95054'

The following query is equivalent to the query above:

    SELECT p.vendor FROM Employee e JOIN e.contactInfo c JOIN c.phones p WHERE e.contactInfo.address.zipcode = '95054'

The spec doesn't specifically define the Employee, ContactInfo, Address, and Phone classes for these queries. There are defined classes in other places of the JPA spec for Employee, ContactInfo, & Address but not for Phone. However, those defined Employee, ContactInfo, & Address classes do not match the attributes defined in these queries. I don't think the first sentence, which briefly describes the ContactInfo embeddable and the Phone entity, is adequate

For example, Section 11.1.2 AssociationOverride Annotation defines a ContactInfo class:

@Embeddable
public class ContactInfo {
    @ManyToOne Address address; // Unidirectional
    @ManyToMany(targetEntity=PhoneNumber.class) List phoneNumbers;
}

The section 4.4.4 example specifies the attribute name for ContactInfo should be contactInfo.phones, not contactInfo.phoneNumbers. Which one is right? Are they the same class even?

Another example is that section 11.1.4 defines an Address class (as well as many other Address class definitions across the specification) :

@Embeddable 
public class Address {
    protected String street;
    protected String city;
    protected String state;
    @Embedded protected Zipcode zipcode;
}

This seems to match what section 4.4.4 is describing, but doesn't work with the section 11.1.2 definition of ContactInfo, which has a Unidirectional ManyToOne relationship to an Address class.

I think the best solution would be to define Employee, ContactInfo, Address, and Phone classes for section 4.4.4. I think the following definitions are accurate for the example and BNF:

@Entity
public class Employee {
    @Id int id;
    @Embedded private ContactInfo contactInfo;
}

@Entity
public class Phone {
    @Id private int id;
    private String vendor;
}

@Embeddable
public class ContactInfo {
    @Embedded private Address address;
    @ManyToMany private List<Phone> phones;
}

@Embeddable
public class Address {
    private String street;
    private String city;
    private String state;
    private String zipcode;
}
m-reza-rahman commented 3 years ago

This looks like a good candidate for a community/end-user contribution. I would suggest marking it with "good first issue" and/or "help wanted". That will help facilitate recruiting people to contribute. I would honestly also mark this low priority.

Reza Rahman Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.