db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Bouschen <mbo.t...@spree.de>
Subject Re: Completeness test and Company model
Date Mon, 29 Aug 2005 15:03:53 GMT
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			

Mime
View raw message