Nevermind pd1 vs pdf support; *this* should seriously make you
reconsider using dependent objects:
http://www.mail-archive.com/ejb-interest@java.sun.com/msg16733.html
<http://www.mail-archive.com/ejb-interest@java.sun.com/msg16733.html>
Jeff
-----Original Message-----
From: Christian Billen [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 19, 2001 7:52 AM
To: Orion-Interest
Subject: RE: Dependents remove not supported
Thanks, I found it 9.4.4.2 page 119 in EJB2.pdf, and tried to use it by
putting the method remove in my DO :
abstract remove();
however Orion doesn't seem to support it and pukes on startup:
"Illegal abstract method in dependent class com.mytest.ejb.MyDo: public
abstract void com.mytest.ejb.MyDo.remove()"
bummer! that seriously make me reconsider using the whole thing, or is
my method signature incorrect?
Christian
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Tim Drury
Sent: Sunday, March 18, 2001 1:58 PM
To: Orion-Interest
Subject: RE: Dependents in 1-N don't go away
You may want to look at 9.4.4.2 in the proposed final draft which
defines the
remove() function of a DO. I don't have PD1 to tell you what section it
is there.
-tim
-----Original Message-----
From: Christian Billen [mailto:[EMAIL PROTECTED]]
Sent: Sunday, March 18, 2001 12:30 PM
To: Orion-Interest
Subject: RE: Dependents in 1-N don't go away
Is that remove() method an abstract method to be implemented in the DO?
they inherit Object and the only required method to implement on them is
the deepCopy(), I don't see where the remove() method is or come from.
Since they are Depedent by nature shouldn't the remove call on the
parent set or collection remove them permanently as well in the design?
maybe it is a bug in Orion ?
Thanks,
Christian
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Tim Drury
Sent: Sunday, March 18, 2001 10:25 AM
To: Orion-Interest
Subject: RE: Dependents in 1-N don't go away
I understand. You have removed the DO from the parents list, but you
have not removed the DO from the database. This is because you did
not call the removed method of the DO. Try:
getDependents().remove(dependent); // remove DO from parent's list
dependent.remove(); // remove DO from database/container
-tim
-----Original Message-----
From: Christian Billen [mailto:[EMAIL PROTECTED]]
Sent: Saturday, March 17, 2001 9:29 PM
To: Orion-Interest
Subject: RE: Dependents in 1-N don't go away
Hi Tim, thanks for the info, by my problem is different
my issue is I want to remove a dependent from the java.utill.Set in its
parent object and that if I call getDependents().remove(dependent) from
the parent object the dependent doesn't go away from the list (even
though it has been found since I implemented the equal method)
Any help on this is really greatly appreciated.
Thanks,
Christian
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Tim Drury
Sent: Saturday, March 17, 2001 9:10 AM
To: Orion-Interest
Subject: 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]
<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
>
>
