> > - the exception model does not work: the container is
> allowed to delay the
> > database write until the end of the transaction, which
> means that the
> > exception occurs *after* all bean instance methods have
> returned. This
> > leaves the client with the nasty job of extracting the
> SQLException from the
> > RemoteException, parsing the vendor-specific message,
> mapping from the
> > database schema to the object level (that was the point of
> CMP, wasn't it?),
> > and finally recovering the beans which have been deleted due to the
> > RemoteException thrown.
>
> A costly validation.
Not really, since its the abnormal case. We only care about the common case.
It's not an option, however, see points above.
>
> >
> > - there is no support at the EB level to query the field
> sizes. Even if I
> > were to do this through JDBC, storing global values in EBs
> is not permitted.
> > Even if I knew the field sizes, they would probably be in bytes, not
> > characters.
>
> Even if the container were to let you query for this this information
> (mapping and DB schema), wouldn't this be expensive to do at runtime?
You would only do this once.
>
> Secondly, such validation would be applicable only when DB fields are
> directly mapped to information in the UI.
>
True. I don't like it either. What are people doing? Hardwiring the field
lengths into the clients?
- Avi
--
s/\be(\w+)/e-\1/g;
===========================================================================
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".
