I'm sure this has been discussed before but I cannot find a thread. I have what I'm sure is a common design issue: I want to use CMP and CMR in general, but for certain queries I will have to use a JDBC SQL call because EJB-QL just doesn't support what I need to do and performing the logic procedurally would be too computationally expensive.
In my case I need to do simple aggregates such as SUM. I can't wait for EJB 2.1.
What problems do I face simply doing JDBC calls against the database? To me it seems the biggest problem is that I cannot depend on a particular relational schema since that is going to be generated at deployment. This means that (theoretically) I do not even know the names of the junction tables that persist the many-to-many relationships (defined abstractly as CMR).
This is doubtlessly manageable if I control deployment, application server and database server. What if I want it to be able to use a different database server (or even app server) ?
Much thanks to anyone who will indulge this poor newbie.
There have been numerous debates on using CMP vs BMP. You can easily do most of the things you want with EJB with BMP .As long as you push all the SQL into a data access layer there are no issues with BMP.
In a CMP itslef you cannot have your own java code as the container generates the SQL for you,
The other option is to use CocoBase or TopLink ( now a part of Oracle) which would provide most of what you want from a OR mapping tool.
I'm not really interested in the debate between BMP and CMP. I know that I cannot have my own SQL in a CMP bean - the methods that performed aggregations would be in a session bean.
I am more interested in knowing if what I want to do is a good design practice with CMP.
To me it seems the biggest problem is that I cannot depend on a particular relational schema since that is going to be generated at deployment.
Um, why do you generate the schema at deployment? Doesn't this lead to some data loss... if you delete your database everytime you deploy. Makes the database kinda reduntant really...
Well, some software developers sell a product. When this product is deployed to a new instance, the database is created. In CMP the creation of the database can be left up to the container, this insulates the deployment package and the software from any vendor-specific code. This means that theoretically I would not know anything specific about the schema used to persist the CMP beans.
What I was interested in is how this can be overcome, if its even a factor etc. If people would never let the container create the schema at deployment I guess that is the sort of thing I wanted to know.
It doesn't really matter anymore since I've abandoned entity beans entirely and am using the DAO pattern with statless session beans to do all my data access.