Hi,
     But i think as per the design patterns , one should always use the Primary key 
class so that if at a later point of time your primary key changes to a
composite primary key then the impact on the code will be minimum. Though the 
possibility of change in primary key is very little. I donot think that having the
own primary key introduces any overhead in performance other than the bit of extra 
coding which the developer has to do,
Please make me correct if i am wrong in my understanding...

Thanks
Manoj

Ashwani Kalra wrote:

> Hi,
> Hicks you are right. He doesnt need compound key.
>
> <prim-key-class>personal.ejb.learning.cmpbean.AccountCMPPK</prim-key-class>
>
> change to
>
> <prim-key-class>java.lang.Integer</prim-key-class>
>
> will suffice I think
>
> Do not use  personal.ejb.learning.cmpbean.AccountCMPPK class as primary
> key.
>
> Cheers
> ______________________________________________
> Ashwani Kalra
> HomePage :  http://www.geocities.com/ashwani_kalra/
> ________________________________________________
>
>                     "Hicks, James"
>                     <James.Hicks@LMBE        To:     [EMAIL PROTECTED]
>                     RRY.COM>                 cc:     (bcc: ashwani.kalra/Polaris)
>                     Sent by: A               Subject:     Re: Problem with Return 
>type of Abstarct get/set methods in
>                     mailing list for         CMP E              ntity  Beans
>                     Enterprise
>                     JavaBeans
>                     development
>                     <EJB-INTEREST@JAV
>                     A.SUN.COM>
>
>                     12/23/2002 11:56
>                     PM
>                     Please respond to
>                     "Hicks, James"
>
> The problem now is that the account number field is a custom type.  Your
> database and application server know nothing about it, so it stores it in
> binary format in your database.
>
> Why are you using a custom PK class?  I see that you only have a single
> field in the class, why not make your account number field an int or long
> and use either a java.lang.Integer or java.lang.Long as the primary key
> class.  This would solve your problem easily.
>
> If on the other hand you want to use a custom PK class, change the account
> number field back to a int and make the changes that I gave you in the
> first email.  Your app server should be match the fields in the pk class to
> the fields in the bean class.
>
> I have seen very few instances where a custom PK class was actually needed.
> They usually come into play when integrating with existing database
> designs.
>
> James Hicks
>      -----Original Message-----
>      From: Manoj Kumar [mailto:[EMAIL PROTECTED]]
>      Sent: Monday, December 23, 2002 11:30 AM
>      To: Hicks, James
>      Cc: [EMAIL PROTECTED]
>      Subject: Re: Problem with Return type of Abstarct get/set methods in
>      CMP Entity Beans
>
>      One more factor which i noticed after changing the return type 'int'
>      to the primary key class 'AccontPK' is that i could deploy my CMP bean
>      however while calling the create method on the bean i was getting data
>      type inconsistency. My underlying table was having the following
>      structure
>
>      SQL> desc account
>       Name                            Null?    Type
>       ------------------------------- -------- ----
>       ACCNUMBER                                NUMBER(7)
>       OWNERNAME                                VARCHAR2(30)
>       BALANCE                                  NUMBER(7)
>
>      When i changed the structure of my table to
>
>      SQL> desc account
>       Name                            Null?    Type
>       ------------------------------- -------- ----
>       ACCNUMBER                                RAW(1000)
>       OWNERNAME                                VARCHAR2(30)
>       BALANCE                                      NUMBER(7)
>
>      then i could run my bean successfully........
>
>      I could not get what was wrong with my earlier table definition. After
>      creating the record when i checked the record in table 'account' ,
>      accountnumber column was having the following value.
>
>      AccountNumber  Column
>      
>ACED000573720028706572736F6E616C2E656A622E6C6561726E696E672E636D706265616E2E4669727374434D50504BB6AD9841A6518F7B0200014900096163634E756D626572787000000066
>
>      It seems that i made some mistake in the deployment descriptor...
>
>      Any suggestions in this regard are welcome !!!!!!!!
>
>      Thanks
>      Manoj
>
>      "Hicks, James" wrote:
>
>           It would help to see your deployment descriptors.  That is
>           probably where your error is.
>
>           James
>
>           -----Original Message-----
>           From: Manoj Kumar [mailto:[EMAIL PROTECTED]]
>           Sent: Monday, December 23, 2002 10:17 AM
>           To: [EMAIL PROTECTED]
>           Subject: Problem with Return type of Abstarct get/set methods in
>           CMP Entity Beans
>
>           Hi,
>           I have created a 'Account' Entity bean having a Primary Key class
>           'AccountPK' which has a AccountNumber field. My bean class has
>           abstarct set/get methods for AccountNumber also. Signatures of
>           these methods is as under
>
>           public abstract int getAccNumber();
>           public abstract void setAccNumber(int accnumber);
>
>           When i tried deploying the Bean in weblgic 7.0, i got the
>           exception saying that the return type of the abstarct methods
>           getAccountNumber should be of primary key AccountPK and not the
>           int. However, all the examples which i could find in tutorials
>           and Books says that the return type should be the data type of
>           the field which in this case is int.
>
>           Thanks in advance!
>
>           Manoj Kumar.
>
>           ===========================================================================
>
>           To unsubscribe, send email to [EMAIL PROTECTED] and include
>           in the body of the message "signoff EJB-INTEREST".  For general
>           help, send email to [EMAIL PROTECTED] and include in the body
>           of the message "help".
>
>           The information transmitted is intended only for the person or
>           entity to which it is addressed and may contain confidential,
>           proprietary, and/or privileged material. Any review,
>           retransmission, dissemination, or other use of, or taking of any
>           action in reliance upon this information by persons or entities
>           other than the intended recipient is prohibited. If you receive
>           this in error, please contact the sender and delete the material
>           from all computers.
>
> The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential, proprietary, and/or
> privileged material. Any review, retransmission, dissemination, or other
> use of, or taking of any action in reliance upon this information by
> persons or entities other than the intended recipient is prohibited. If you
> receive this in error, please contact the sender and delete the material
> from all computers.
>
>   ------------------------------------------------------------------------
>                                Name: InterScan_Disclaimer.txt
>    InterScan_Disclaimer.txt    Type: Plain Text (text/plain)
>                            Encoding: 7bit

===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".

Reply via email to