Hi Craig,
I checked in the changes.
Regards Michael
Hi Michael,
On Aug 29, 2005, at 8:03 AM, Michael Bouschen wrote:
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.
Yes, I adapted them by removing the add and remove methods, and I didn't
want a dependency between the two packages.
- 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.
Yes, I wanted to make sure there were no other possible dependencies,
and wanted some feedback before removing them.
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?
Let's do it.
Craig
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
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
