I have always been amazed that support for auto-generated primary keys
is not a part of the EJB specification. The list archives are full of
questions about this. Since nearly all databases support some sort of
efficient key generation, and the EJB container can compensate for the
ones that don't, why isn't this provided for in the spec?!?
It seems so simple, too. If the primary key is an integer type (or even
just Long), and is not set in ejbCreate(), then the container should be
responsible for generating the key. This small change would make me and
countless other EJB developers extraordinarily happy :-)
Jeff Schnitzer
[EMAIL PROTECTED]
Using XSLT? Try the Maverick MVC Framework: http://mav.sourceforge.net
> -----Original Message-----
> From: Richard Monson-Haefel [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, June 16, 2001 9:52 AM
> To: [EMAIL PROTECTED]
> Subject: CMP 2.0: Auto-generated primary keys
>
>
> With auto-generated primary keys the value of the primary key is
> obtained from the container, which may generate the key itself or use
> some kind of auto-generate facilities of the database, like
> auto-increment.
>
> If I want a CMP 2.0 entity bean, say the Customer EJB, to use a
> auto-generated primary key of type Integer, then it appears
> that I would
> have to declare the primary key as "undefined" or "deferred" at bean
> development time. Is that correct?
>
> Can I define the primary key type, but not corresponding persistent
> fields? If you define abstract accessor methods for primary key's
> field(s), then you must set the primary key field in the ejbCreate()
> method (sec. 10.3.5), which I don't want to do with auto-generated
> primary keys. I want the container to set auto-generated keys.
>
> Is the following valid?
>
> public abstract class CustomerBean implement EntityBean {
>
> public Integer ejbCreate( ){}
> public void ejbPostCreate(){}
>
> public abstract String getLastName(){}
> public abstract void setLastName(){}
> public abstract String getFirstName(){}
> public abstract void setFirstName(){}
>
> // call back methods
> }
>
> public interface CustomerHome extends EJBLocalHome{
>
> public Customer create() throws CreateException;
>
> public Cusotmer findByPrimaryKey(Integer primKey)
> throws FinderException;
> }
>
> // deployment descriptor
> <ejb-jar>
> <enterprise-beans>
> <entity>
> <ejb-name>CustomerEJB</ejb-name>
> <local-home>CustomerHome</home>
> <local>Customer</remote>
> <ejb-class>CustomerBean</ejb-class>
> <persistence-type>Container</persistence-type>
> <prim-key-class>java.lang.Integer</prim-key-class>
> <reentrant>False</reentrant>
> <cmp-version>2.x</cmp-version>
> <cmp-field><field-name>lastName</field-name></cmp-field>
> <cmp-field><field-name>firstName</field-name></cmp-field>
> </entity>
>
> Notice that a primkey-field is not specified and that neither of the
> persistent fields match the prim-key-class type.
>
> Richard
>
> --
> Richard Monson-Haefel
> Author of Enterprise JavaBeans, 2nd Edition (O'Reilly 2000)
> Co-Author of Java Message Service (O'Reilly 2000)
> http://www.jMiddleware.com
>
> ==============================================================
> =============
> 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".
>
>
==========================================================================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".
