Community
Participate
Working Groups
When generating entities from a database with EMPLOYEE and PHONENUMBERS tables with a OneToMany from EMPLOYEE to PHONENUMBERS, the default Entity names are Employee and Phonenumbers. If the default is overridden and Phonenumbers is renamed PhoneNumbers, the Entities are generated with the correct names. However the getter for PhoneNumbers on Employee is generated as getPhonenumbers() and not, as expected, getPhoneNumbers(). The getter generation does not correctly reflect the camel casing of the target Entity and should.
Targeting to head based on non-major severity of this issue.
I am not able to reproduce. The generated getter/setter code does preserve the camel case: //bi-directional many-to-one association to Phonenumber @OneToMany(mappedBy="employee") private Set<Phonenumber> phoneNumbers; public Set<Phonenumber> getPhoneNumbers() { return this.phoneNumbers; } Tested on Oracle with following SQL: drop table EMPLOYEES create table EMPLOYEES (NAME VARCHAR(100) not null); alter table EMPLOYEES add constraint PK_EE primary key (NAME); drop table PHONENUMBER create table PHONENUMBER (NO VARCHAR(100) not null, EMPLOYEE_NAME VARCHAR(100) not null); alter table PHONENUMBER add constraint PK_SURVEY primary key (NO); ALTER TABLE PHONENUMBER add constraint EMPLOYEE_NAME FOREIGN KEY (EMPLOYEE_NAME) REFERENCES EMPLOYEES (NAME);
Shaun, can you try again and let me know if still reproduced?
I can reproduce this Danny. I created tables on a derby database. Then generated entities and renamed the default entity name Phonenumber to PhoneNumber. Employee was generated with: private Set<PhoneNumber> phonenumbers; public Set<PhoneNumber> getPhonenumbers() { return this.phonenumbers; } public void setPhonenumbers(Set<PhoneNumber> phonenumbers) { this.phonenumbers = phonenumbers; } I don't understand the code that you have posted. How is the class name Phonenumber with a lower case 'n' and the field/getter/setter have a capitalized 'N' for Number? That looks like the opposite problem and I don't see how that could happen.
I just stumbled across what I think is really going on here. Both Karen and I think that changing the name of an Entity from Phonenumber to PhoneNumber should change the getter/setter on Employee. But the getter/setter is based on the Employee.phonenumber property name which does not seem to be affected by the class rename. So the real "bug" here is that the property of Employee is not changed Employee.phoneNumber when the default Phonenumber class name is changed to PhoneNumber. If this were to happen the getter/setter would generate fine.
Oh duh, I *knew* there was something fishy going on, thanks for clearing that up Shaun. So that complicates things further since the 'phonenumbers' property is defined on an earlier page of the entity gen wizard than the entity name. Might be weird to have the wizard modify that after already completing that wizard page.
It appears that we need to define the entity class name before the table associations so that those property names can be dependent on the entity class name. Possibly we could move the 4th wizard page to the 2nd position. Or move the 2nd wizard page to the end. Not sure about changing up the flow this late in the cycle. Or maybe class names should be defined separately. In our original entity gen wizard the class names were defined where you selected the tables. It was a checkbox table with 2 columns : 'table' and 'class name'. The class name is probably something that is change a lot and it's on the last wizard page.
Right, that was what I did: to change getter/setter method names of an OTM,OTO association, I change the property name of the association, not the target Entity name. Changing association property name based on target entity name is problematic: since the target entity may be referenced by different entities. User may actually want to uses a more meaningful and possibly different property name to represent the target entity within each context. Moving the 4th wizard page to the 2nd position is not a trivial change. I need revisit the existing code to see what the impact will be.
It looks like this is going to be more of a functional change than a bug fix. As a result, I'm going to defer this to the next release.
Moving JPA specific bugs to new JPA component in bugzilla.
