EJB-QL : How does is fare with SQL

[Rishi Singh]

Hi All,
While writing the Ejb-ql for ejbSelect() and ejbFind() we normally use the SQL syntax with some basic constructs like OBJECT operator and the different variants like WHERE,IN clause, still if we need to make some complex joins involving a aggregate Entity pattern , its limitations are exposed. How is sun proposing to make this full-fledged wherein the developer have the freedom of writing concrete DML's
Rishi
SCJP,SCWCD,IBM OOAD

[Prashant Satarkar]

Hi All and Hi Rishi,
Jus got to know about the forum. ok, ur qs first? Last yr when i saw the specs about EJB-QL specs and started woreking on this. the first thing which came to my mind was, why EJB-QL in the first place?
When the SQL is such an easy, powerful and accepted language, why do the sun people require some other language for database? The developers already are pretty conversent with SQL. so, according to me, it really does not make sense to have somethign like this.
but its there... and that too with lots of limitations, like u rightly said, complex joins cannot be catered thru EJB-QL.
Lets see how Sun wants to go about solving the limitations thing from this language. I am also waiting for an answer about this.
Prash

[Pradeep bhatt]

There are many things missing IN EJBQL such ORDER BY clause. This had been intorduced in EJB 2.1 but there are many shortcomings such as using Dates etc.

[viswanadh kasinadhuni]

hi prashant,
First of all everything is reinvented by sun..like entity beans...its concept is nothing but like views of a rdbms..right. ofcourse they have a lot more advantages than views..but still the basic is duplication of data and now EJB-QL for querying the objects..another duplicate work. why not just use session beans and use sql and rdbms avoid entity beans completely. Lets wait and see what SUN says about this.

[krithika desai]

Originally posted by viswanadh kasinadhuni:
hi prashant,
First of all everything is reinvented by sun..like entity beans...its concept is nothing but like views of a rdbms..right. ofcourse they have a lot more advantages than views..but still the basic is duplication of data and now EJB-QL for querying the objects..another duplicate work. why not just use session beans and use sql and rdbms avoid entity beans completely. Lets wait and see what SUN says about this.

So you are basically questioning the Object-Relational mapping then which is what entity beans ultimately do?

[Sainudheen Mydeen]

Originally posted by viswanadh kasinadhuni:
why not just use session beans and use sql and rdbms avoid entity beans completely. Lets wait and see what SUN says about this.

When working with large volume of data, which one is easy to implement and provides better performancea? EntityBean OR JDBC?
-Sainudheen

[krithika desai]

Originally posted by Sainudheen Mydeen:

When working with large volume of data, which one is easy to implement and provides better performancea? EntityBean OR JDBC?
-Sainudheen

From the discussions in the EJB forum , looks like finders and ejbSelects and bean traversal through CMRs results in lots of performace issues when dealing with huge volumes of data. So JDBC is the recommended way atleast when processing existing data ( ie read only ).

[Pradeep bhatt]

If you coding some seatch functionality use session beans +JDBC.

[Sivasundaram Umapathy]

In one of my projects,initially finders were used to return data for read only purpose.But the performance suffered a lot.Later we replaced them using session+JDBC and in cases where transactions were not required,we simply used a POJO helpers+ JDBC.

[Rishi Singh]

Hi All,
As pointed out earlier, in case of read -only data i think SessionBean - JDBC is the most preferred. In case of data data which needs manipulation,
the choice boild down to how much control one wants in the transaction, or rather it should be left to the container itself. With changes in EJB-QL , and local interfaces I think EntityBean is worth a look .
Rishi
SCJP,SCWCD,IBM OOAD