Murali Krishna Devarakonda wrote:
> What I'd like to see is EJB technology supporting sophisticated CMP
> itself. I don't think the "use_an_OR_Mapping_tool" direction that some of us
> are being forced to adopt is right.
Among our customers, I see two distinct requirements for CMP.
(1) CMP where the customer wants persistent objects, and couldn't care at all
where or how their data is stored. (The spec allows Java Serialization to
be used in this case).
(2) CMP where the bean's persistence must map to database schemas that already
exist or are created by the customer (in the RDBMS case, they may sometimes
want to be able to use SQL to access their data).
Where the customer wants the latter, I believe that tools that generate BMP
code are an essential part of the equation, since no matter how 'clever' a CMP
code generator is, it might not be adequate to meet the customer's requirements,
so generating BMP code that the user can then modify is very useful.
The back-end data sources that are accessible through CMP (or BMP) are so many
and varied that I am not clear on what "Standard CMP" would look like. Once you
have declared which fields in your bean are your "persistent state", anything
else (apart from caching-type optimizations like being able to specify in the
deployment descriptor that a method is read-only) is specific to the data
store being used.
I would propose to the spec writers that the notion of 'read-only' method be
specifiable in the deployment descriptors.
________________________________________________________________________________
Evan Ireland Sybase EA Server Engineering [EMAIL PROTECTED]
Wellington - New Zealand +64 4 934-5856
===========================================================================
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".
