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 17:17:06 GMT
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: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!
> 
> 


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