db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig Russell <Craig.Russ...@Sun.COM>
Subject Re: Completeness test and Company model
Date Mon, 29 Aug 2005 15:07:47 GMT
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.

> 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
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!

View raw message