Entity EJB and SQL

[roul ravashimka]

hello,
is it possible to work with sql instead of ejb-ql for writing a finder method of a entity ejb?
Thanx,
roul

[Anna Madhusudhanan Natanagopalan]

Hi Roul,
I don't think so.
if anyone knows the clear explanation for this one, please...
Thanks and regards
Anna Madhusudhanan

[Paul Sturrock]

Sorry no. If you find that you need more SQL-like functionality than EJBQL provides (and it is a limited subset of SQL so most people do) have a look at vendor-specific extensions (I haven't used Entity Beans in a long time, but WLSQL used to offer quite a lot, I presume this is true of other sevrers?). If you want to keep things portable, and use more SQL functionality, consider a persistance layer other than Entity Beans.

[roul ravashimka]

Thx,
wouldn't it be possible to work with stored procedures which are called from the entity ejb?
roul

[Kyle Brown]

No, not without specific vendor extensions.
Kyle

[roul ravashimka]

thx,
So, when using entity ejb's we have to use ejb-ql, which has less possibilities then sql.
If we want to use sql, we use a data acces object.
am i correct?

[Nathaniel Stoddard]

Roul,
I suppose you could always do it in a home method, which returns a collection of primary keys (or one). Then you could use them immediately through a findByPrimaryKey and continue in EJB instead of JDBC.
The reason why you can't do SQL instead of/in EJB-QL is because EJB-QL goes along with the schema for CMP. There are some limited functions that may be available. If I had to choose between vendor enhancements to EJB-QL or using JDBC, I'm probably opt for the container-independent version though--that is using JDBC also.
You could also just do a home method that uses a select or find and then further filters it using regular method invocations on the objects returned. (Lots of possibilities, all of which are very valid in lots of situations I think.)