RE: Dependents remove not supported
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",
RE: Dependents remove not supported
Christian look at : http://www.mail-archive.com/orion-interest@orionserver/msg113324.html Not a very good solution, but it is one. regards /Theis.
RE: Dependents remove not supported
Title: RE: Dependents remove not supported It doesn't support ejbCreate either. The container never calls this method and if you have arguments (i.e. ejbCreate(String pleaseWork) it would result in an error from Orion. hmm, I have ejbCreate() with and without args. While I never called my DO's with args, it doesn't give an error. I always call the default ctor then use setters. I ought to call the ctors with args to see what happens. Relations between dependents are not supported. Orion returns an error on the abstract create method. This is very true. I discovered this some time ago - bug #185. My solution to the DO issue was to use EJBs for everything. This may have been a good choice since DO's in the spec are under a lot of fire and may be radically changed. EJB-EJB calls within the same container are optimized to local call-by-value method calls (at least in orion), so speed between all these EJBs isn't much of an issue. -tim
RE: Dependents remove not supported
Title: RE: Dependents in 1-N don't go away
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
DrurySent: Sunday, March 18, 2001 1:58 PMTo:
Orion-InterestSubject: 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 PMTo: Orion-InterestSubject: 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
DrurySent: Sunday, March 18, 2001 10:25 AMTo:
Orion-InterestSubject: 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 PMTo: Orion-InterestSubject: 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
DrurySent: Saturday, March 17, 2001 9:10 AMTo:
Orion-InterestSubject: 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
RE: Dependents remove not supported
Title: RE: Dependents in 1-N don't go away I was under the impression that the container implemented remove() for you to simply delete the DO from the database. When you call "depobj.remove()" from the DO's parent, it gets deleted. I could be wrong - it wouldn't be the first time. -tim -Original Message-From: Christian Billen [mailto:[EMAIL PROTECTED]]Sent: Monday, March 19, 2001 10:52 AMTo: Orion-InterestSubject: 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 DrurySent: Sunday, March 18, 2001 1:58 PMTo: Orion-InterestSubject: 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 PMTo: Orion-InterestSubject: 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 DrurySent: Sunday, March 18, 2001 10:25 AMTo: Orion-InterestSubject: 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 PMTo: Orion-InterestSubject: 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 DrurySent: Saturday, March 17, 2001 9:10 AMTo: Orion-InterestSubject: 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 equa
RE: Dependents remove not supported
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
getPhone
RE: Dependents remove not supported
Title: RE: Dependents in 1-N don't go away Well no that's the prob, spec says you can have an abstract remove method in the DO but it looks like it's not an implemented feature. Has anyone on the list been able to delete specific dependents from a parent ejband can maybe share how they do it? Thanks, Christian -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tim DrurySent: Monday, March 19, 2001 12:16 PMTo: Orion-InterestSubject: RE: Dependents remove not supported I was under the impression that the container implemented remove() for you to simply delete the DO from the database. When you call "depobj.remove()" from the DO's parent, it gets deleted. I could be wrong - it wouldn't be the first time. -tim
RE: Dependents remove not supported
Tim Drury wrote: I was under the impression that the container implemented remove() for you to simply delete the DO from the database. When you call "depobj.remove()" from the DO's parent, it gets deleted. I could be wrong - it wouldn't be the first time. That's true! However Orion does not yet seem to support remove on dependent objects. It doesn't support ejbCreate either. The container never calls this method and if you have arguments (i.e. ejbCreate(String pleaseWork) it would result in an error from Orion. Relations between dependents are not supported. Orion returns an error on the abstract create method. You can have relation between DO and Entity (i.e. do - entity), but Orion creates the tables wrong and therefore it also seems that this is not yet supported. Dependent objects cannot have primary keys. But as Jeff, with a reference to another guy, pointed out this seems to be a typo in the spec. I totally agree. I also checked referential integrity and data aliasing in the persistence manager and here the guys behind Orion have lot to do. Or, maybe it is up to the programmer to uphold the cardinality and check for duplicates (what do you think?). Anyway I did some tests: If you have to entities that have a reference to the same DO and you change the DO by one entity, the reference that the second entity holds on to is not updated (data aliasing). You could also easily break the referential integrity (in the persistence manager). I you have a unidirectional one to many relationship between entities, it is possible to let entities on the many side to refer to the same entity in the one side. I could be wrong in these statements. If I am, please correct me. Regards, /Theis.
