The PFD spec says that you do not need to specify a remove method
(container will do that automatically)
Having said all that, you should not ignore all the warnings about using
dep objs. There's a VERY strong chance that they're being gotten rid of. I
also suspect that because of that, Orion's impl of dependent objects won't
have much effort or time put into it, until their fate is resolved one way
or another. By the way, this isn't just 'mere speculation', the removal of
dependent objects is something that many people directly involved with the
expert group have hinted at.
On Mon, 19 Mar 2001, Christian Billen wrote:
> RE: Dependents in 1-N don't go awayThanks, 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]]
> > 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
> >
> >
>
>
