Hi Craig,
the changes look good, just two comments:
- Do we still need the interfaces in the icompany package?
With revision 263928 you added pc interfaces (such as ICompany,
IDepartment, etc.) to the company package. They are more or less the
same as the ones in the icompany package, so I am wondering whether we
need both of them.
- Class EqualityHelper provides overloaded equals methods: one version
taking the two values to compare and another version taking an
additional string describing the locality of the inequality, e.g.:
public boolean equals(int p1, int p2)
public boolean equals(int p1, int p2, String where)
I think we can skip the methods taking two arguments.
I removed the icompany interfaces and commented out the EqualityHelper
equals methods taking two arguments in my workspace. It compiles and
runs successfully. If you agree I can check in this cleanup change.
What do you think?
Regards Michael
Hi,
I've looked closely at the strategy for making persistent interfaces and
concluded that we cannot split out the "getters" from the "setters" in
the interface. The spring framework doesn't allow asymmetric get and set
methods. In particular, in Employee class, if we have a method void
setDepartment(Department), we must have a method Department
getDepartment(). It's not allowed to have void setDepartment(Department)
and have IDepartment getDepartment().
So I've updated the company package to add the interface classes. I had
to remove the extraneous add and remove methods since these are not bean
pattern methods.
I've also implemented the DeepEquals.deepCompareFields and
EqualityHelper.equals(Object, Object, String). They have allowed me to
see where the relationship tests are failing.
Here's a sample of what to expect:
public boolean deepCompareFields(Object other,
EqualityHelper helper) {
IPerson otherPerson = (IPerson)other;
String where = "Person[" + "]";
return
helper.equals(personid, otherPerson.getPersonid(), where +
"(personid)") &
helper.equals(firstname, otherPerson.getFirstname(), where +
"(firstname)") &
helper.equals(lastname, otherPerson.getLastname(), where +
"(lastname)") &
helper.equals(middlename, otherPerson.getMiddlename(), where
+ "(middlename)") &
helper.equals(birthdate, otherPerson.getBirthdate(), where +
"(birthdate)") &
helper.deepEquals(address, otherPerson.getAddress(), where +
"(address)") &
helper.deepEquals(phoneNumbers,
otherPerson.getPhoneNumbers(), where + "(phoneNumbers)");
}
The tests are failing in navigating from Employee to medicalInsurance.
The code is apparently not constraining the query to just instances of
medical insurance, so it's retrieving rows that were stored as dental
insurance. This causes two distinct behaviors: classCastException while
lazy loading the medical insurance field with application identity, and
failure to compare while lazy loading the medical insurance field with
datastore identity.
I've double checked the metadata and now I'll take a look at the jpox
log. Might be something interesting there. And I'll file a JIRA issue.
Craig
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
--
Michael Bouschen [EMAIL PROTECTED] Engineering GmbH
mailto:[EMAIL PROTECTED] http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
