|
Home > Archive > Apache JDO Project > August 2005 > Completeness test and Company model
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Completeness test and Company model
|
|
| Craig Russell 2005-08-28, 2:45 am |
| | |
| Michael Bouschen 2005-08-29, 5:45 pm |
| 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:Craig.Russell@sun.com
>
> P.S. A good JDO? O, Gasp!
>
>
--
Michael Bouschen Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
| |
| Craig Russell 2005-08-29, 5:45 pm |
| | |
| Michael Bouschen 2005-08-29, 5:45 pm |
| Hi Craig,
I checked in the changes.
Regards Michael
> Hi Michael,
>
> On Aug 29, 2005, at 8:03 AM, Michael Bouschen wrote:
>
>
>
> Yes, I adapted them by removing the add and remove methods, and I didn't
> want a dependency between the two packages.
>
>
>
> Yes, I wanted to make sure there were no other possible dependencies,
> and wanted some feedback before removing them.
>
>
>
> Let's do it.
>
> Craig
>
>
> Craig Russell
>
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>
> 408 276-5638 mailto:Craig.Russell@sun.com
>
> P.S. A good JDO? O, Gasp!
>
>
--
Michael Bouschen Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
|
|
|
|
|