| Quoted table names in @Column(..., table = "\"Addresses\"") produces DescriptorE [message #1834755] |
Tue, 17 November 2020 07:30  |
Eclipse User |
|
|
|
Hello all.
I seem to have found an issue with EclipseLink using the following mapping:
@Entity
@Table(name = "\"Contacts\"")
@SecondaryTable(name = "\"Addresses\"", pkJoinColumns = @PrimaryKeyJoinColumn(name = "contact_id", referencedColumnName = "id"))
public class Contact implements Serializable
{
private static final long serialVersionUID = 1L;
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
@Column
private Integer id;
@Basic
@Column(name = "country_code", table = "\"Addresses\"")
private String countryCode;
@Basic
@Column(name = "zip_code", table = "\"Addresses\"")
private String zipCode;
@Basic
@Column(name = "city_name", table = "\"Addresses\"")
private String cityName;
@Basic
@Column(name = "street_name", table = "\"Addresses\"")
private String streetName;
@Basic
@Column(name = "house_nbr", table = "\"Addresses\"")
private String houseNbr;
When deploying the app on WildFly, everything is fine. Requesting some page then throws a DescriptorException:
Exception [EclipseLink-93] (Eclipse Persistence Services - 2.7.7.v20200504-69f2c2b80d): org.eclipse.persistence.exceptions.DescriptorException
Exception Description: The table ["Addresses"] is not present in this descriptor.
Descriptor: RelationalDescriptor(net.bbstatstest.i286.entity.Contact --> [DatabaseTable(Contacts), DatabaseTable(Addresses)])
I placed the whole thing onto SO here: https://stackoverflow.com/questions/64868818/eclipselink-the-table-addresses-is-not-present-in-this-descriptor-descripto
Standard JPA quoting of table names should be supported here, right?
Is this a bug?
Karsten
[Updated on: Tue, 17 November 2020 11:10] by Moderator
|
|
|
| Re: Quoted table names in @Column(..., table = "\"Addresses\"") produces Descrip [message #1835321 is a reply to message #1834755] |
Mon, 30 November 2020 10:58  |
Eclipse User |
|
|
|
Seems a bug. EclipseLink stores this as a databaseField object, with a string "Address" and case sensitivity boolean set to enabled. This allows it to not have to look in returned SQL for a non-existing "\"Addresses\"" string, but likely plays into this issue where further definitions and lookups internally might reuse it. Hopefully it is something easily fixed within the annotation parsing, but is more complicated if this is to be fixed and allow backward compatibility with the workaround:
Workaround you've already worked out is to define "\"Addresses\"" in the SecondaryTable annotation and then just use "Addresses" elsewhere.
|
|
|
Powered by
FUDForum. Page generated in 0.03865 seconds