im not very experienced in EJB QL, and i have a small problem. Im developing an "advance search" (when the primary key is not known) where people can fill in what they do know about a particular database entry.
So... when I write my EJB-QL query for my ejbSelect method, it gets tricky. The problem is that not all parameters will be filled in by the user. So I cant write my EJB-QL query like: SELECT OBJECT (o) FROM TestSchema o WHERE o.parameter1 = ?1 AND o.parameter2 = ?2 AND o.parameter3 = ?3 AND o.parameter4 = ?4
Those parameters that arn't filled in by the user... how can I make my EJB-QL query to understand that i dont want any filtration of that particular parameter? In SQL you could simply replace an empty string with "*". But you cant do that in EJB-QL. Any suggestions?
[ February 03, 2007: Message edited by: Kalle Anka ]
[ February 03, 2007: Message edited by: Kalle Anka ] [ February 03, 2007: Message edited by: Kalle Anka ]
by JDBC you mean writing SQL queries directly to the database right? Wouldnt I then need to open a database connection in my entity bean? And wouldnt that be considered to be bad programming when your using J2EE?
If using JDBC... should i change my ejbSelectXXX to another method ejbWhatever and where I make my sql query?
Originally posted by Kalle Anka: by JDBC you mean writing SQL queries directly to the database right?
Wouldnt I then need to open a database connection in my entity bean? And wouldnt that be considered to be bad programming when your using J2EE?
You wouldn't do this from within the EJB. You would have whomever is calling the EJB finder call the JDBC class instead. So the JDBC code goes in a new class (typically called a DAO - data access object.) Then your servlet or session bean (or whomever is calling the entity bean now) calls the DAO.
It would be considered bad programming to call JDBC within an entity bean. However, JDBC is not prohibited or even discouraged when using J2EE. There is no rule or best practice stating you must limit yourself to entity beans.
[edited to fix quotes] [ February 04, 2007: Message edited by: Jeanne Boyarsky ]
For EJB 2.x, the best overall architecture is to not use Entity Beans, hence also no EJB-QL, but use an ORM tool, like Hibernate, Ibatis, or TopLink, they have much more expressive querying language to allow such a query. You should probably avoid JDBC because of how much code it takes to do your work. It will consume about 30% of your code, whereas an ORM tool will do most of your work under the covers.
For EJB 3.0 Entity Beans are now part of the JPA Java Persistence API/Architecture, and is basically a specification for an ORM tool. And would be the route to go.