You know I thought someone would diverge entirely from the spirit of the
question. I'm just surprised it was Frank. Please start another thread next
time.
Yes, the app I am working on right now deals in currency > $1 Trillion
dollars, and yes it could be written with longs. But the Sybase database
JDBC driver maps numeric types to BigDecimal. It made sense for us and it
works well.
jim
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Frank Sauer
> Sent: Monday, October 04, 1999 9:58 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Doubts about Entity beans, Should we use them?
>
>
> Which brings up another question that has been bugging me for
> the longest time now. Why does everyone use the BigDecimal class
> for numbers? Do we really have orders with balances requiring
> hundreds or thousands of digits? What's wrong with using the Java
> primitives, or - if you want Objects because you need an 'undefined'
> value - with the simpler wrapper classes like Integer?
>
> Frank
>
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of James Cook
> Sent: Monday, October 04, 1999 8:50 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Doubts about Entity beans, Should we use them?
>
>
> I'm sure I'm missing the point. We are trying to demonstrate why
> BMP cannot
> be optimized as much as CMP. We are also looking hard at the finder method
> for entity beans. To find orders with balances > $100 we would have the
> following BMP query in the Order home...
>
> public Enumeration ejbFindByBalance(BigDecimal amount) throws ...
>
> in this finder we will issue the appropriate SQL to create a bunch of
> Primary Key objects and stuff them into an enumeration.
>
> If the client is the GUI side of an application and wishes to stuff the
> customer names from these orders into a list box, a separate remote call
> would be necessary to obtain the names. This would be required
> whether using
> CMP or BMP, and you should be whipped with a wet noodle for not using a
> session bean.
>
> So what's the deal with CMP? Can the containers optimise the subsequent
> remote getCustomerName() calls because they instantiated all of those
> objects when they did the original finder query? If so, wouldn't
> this be an
> incredible waste of time if my client simply wanted to report the
> number of
> large orders?
>
> I'm not sure if I see the scenario that is causing the grief. Please help.
>
> jim
>
> > -----Original Message-----
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Chris Raber
> > Sent: Friday, October 01, 1999 6:35 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Doubts about Entity beans, Should we use them?
> >
> >
> > Muly,
> >
> > Yes the spec is written that way. But there is nothing that
> says your BMP
> > implementation can't cache the results of the initial query. Some BMP
> > generators <vendor> Cocobase </vendor> will write this code for you...
> >
> > -Chris.
> >
> > > -----Original Message-----
> > > From: Muly Oved [SMTP:[EMAIL PROTECTED]]
> > > Sent: Friday, October 01, 1999 4:51 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: Doubts about Entity beans, Should we use them?
> > >
> > > >If the original request was "Get me all employees", then the
> > > corresponding
> > > >find()
> > > >method in case of BMP might use one query
> > >
> > > >SELECT PKEY, FNAME, LNAME FROM EMP
> > >
> > > >to build the enumeration of primary keys AND entity bean for each
> > > employee,
> > > >which
> > > >will remain in cache until used by the caller.
> > >
> > > I don't think this can be done with BMP, as the result of the ejbFind
> > > should be an enumeration of primery keys, then the continer take every
> > > primery key and use ejbLoad to load the rest of the fields.
> > >
> > > The spec limit the way this find is solved, this is where CMP has more
> > > space for optimization.
> > >
> > > muly.
> > >
> > >
> >
> ==========================================================================
> > > =
> > > 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".
> >
> >
>
> ==================================================================
> =========
> 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".
>
>
===========================================================================
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".
