Title: RE: Dependents in 1-N don't go away

Dependent objects (DO) do not go away automatically.
There is an un-implemented option in the deployment
descriptor called <cascade-delete>, but alas, it is
unimplemented.

The DO life-cycle is one of the main issues with DOs
in the spec and one reason they may be changed.

For now, just implement ejbRemove in your entity
and DOs so they call the remove of their children.

-tim


> -----Original Message-----
> From: Christian Billen [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 16, 2001 7:43 PM
> To: Orion-Interest
> Subject: Dependents in 1-N don't go away
>
>
> Hi everyone,
>
> I am having an issue with my 1-n dependents relationship.  My
> dependents
> don't get deleted when I remove them from the cmr Set.
>
> I have a PhoneNumber dependent class which has a field type,
> countrycode,
> number, etc...
>
> I implemented the equal method in my class such that two
> phonenumber having
> the same type are equal, these type being like "business",
> "fax", "cell",
> etc
>
> Now I have an ejb class, the Customer ejb, which has :
>
> abstract PhoneNumber createPhoneNumber()
> abstract Set getPhoneNumbers()
> abstract void setPhoneNumbers(Phonenumber n)
> void addPhoneNumber(String type, String areaCode, ...)
> {
>       PhoneNumber p = createPhoneNumber();
>       //Remove an existing phone
>       //*1
>       getPhoneNumbers().remove(phoneNumber);
>       //*2
>       getPhoneNumbers().add(phoneNumber);
>       //*3
> }
>
> Basically since my phonenumber equals on type, the desired
> effect is I want
> to wipe out a previous phonenumber of the same type before
> adding the new
> one.
>
> My problem is that I can see the phoneNumber being
> successfully removed from
> the list by putting debug calls at *1,*2 and *3 that checks on
> getPhoneNumbers.size() ...and the method commits correctly. 
> But the rows
> are still in the database.  Which if I call this method again
> will cause a
> Duplicate Key exception from my DB.
>
> Anyone knows why the remove() call doesn't seem to affect the db?
>
> Note: I run within container transaction on this method.
>
> Thanks,
>
> Christian
>
>

Reply via email to