Re: Embedding fields of non-persistent types even when field-type is used

[Craig L Russell]

Hi Andy,






Craig

On Jul 27, 2007, at 10:50 PM, Andy Jefferson wrote:

I agree that we're getting a bit far from reality with the framework that we set up for deepEquality testing. It appears that a reflection- based approach might work if we are unsuccessful in getting JPOX to work with this artificial setup. Michelle and I have already prototyped a reflective approach for comparing two object graphs. So that's our Plan B in case it's too much work to force-fit JPOX persistent interface.

Hi Craig, Michelle,

The problem is that if you declare the PI* address property in
PICompany as
PIAddress getAddress()
void setAddress(PIAddress)

then it doesn't implement ICompany any more, since you also need
these from the ICompany interface:
IAddress getAddress()
void setAddress(IAddress)

And of course these are the methods that the e.g. FC classes
implement by casting the input IAddress to FCAddress. Which is what
we want the generated PICompanyImpl to do because we specify that the
type of the field is PIAddress.

that "companyPMInterface.conf" complains about

PIInsurance has no <property field-type="..."> on field "employee".
PIDSInsurance has no @Persistent(types=) on field "employee".

Fix those and re-run, you then get the error on

PIDSEmployee etc

When those are fixed there are likely some others.


not persistent. Maybe JPOX will cope ?





staring at it for several minutes causes madness to set in ...

--
Andy  (Java Persistent Objects - http://www.jpox.org)

There are still places where there is no "types" (annotations) or "field-type" (XML) specified on overridden interface fields. I'll start from the one PIEmployee "dentalInsurance", "medicalInsurance", "department", "fundingDept", ... Only when *all* of these are added can we address if JPOX can cope with that structure or not. As it is currently there are persistent properties that are PS. Let's face it, the persistent-interface structure is an artificially constructed case that is no longer representative of the real world, and

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!

smime.p7s
Description: S/MIME cryptographic signature