• Post Reply Bookmark Topic Watch Topic
  • New Topic

Using EJB-QL LIKE and a replacable param(?1).  RSS feed

 
Paul Roubekas
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My J2EE container vendor will not deploy the following.

The way I read Chapter 11 'EJB QL: EJB Query Language for Container-Managed Persistence Query Methods' of the spec it should work.
Has any had success with the use of LIKE and the replaceable token ?1. If yes what J2EE container vendor are you using?
 
Chris Mathews
Ranch Hand
Posts: 2712
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Input parameters are not supported by the like expression in EJB 2.0.
From the Spec:

Input parameters can only be used in comparison_expressions or collection_member_expressions, as defined in Section 11.4, "EJB QL BNF"

The like expression is neither a comparison_expression or a collection_member_expression. Thus it is not supported with input parameters.
This is one of the limitations of EJB QL that makes it very hard to use on real projects. This is also being addressed in EJB 2.1. Date comparisons will be a part of EJB QL in 2.1 also.
[ September 20, 2002: Message edited by: Chris Mathews ]
 
Chris Mathews
Ranch Hand
Posts: 2712
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
BTW, this and other functionality was supported in the Proposed Final Draft of EJB 2.0 but ended up being dropped before the Final Release. Check to make sure the EJB Specification that you are reading is the Final Release.
 
Paul Roubekas
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ugg!
Thanks Chris I did not see that point in section 11.2.7.4
And if you read the EJB 2.1 specification draft the focus is on Web Services, not adding features that a serious developer needs. Too many companies chasing hype and not enough developers in the expert group drafting the specifications if you ask me!
 
Rick Hightower
Author
Ranch Hand
Posts: 350
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree that it is not supported by the Specification.
It does work with Resin EE and WebLogic.
Just curious, which vendor are you using?
(I know it does not work with JBoss)
 
Paul Roubekas
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
MacroMedia's JRun version 4.
In an effort to find a work around I tried
SUBSTRING(object.cmpFieldName, ?1, ?2) = ?3
and that is not supported by the spec. either!
SUBSTRING() does not take replacement tokens.
 
Chris Mathews
Ranch Hand
Posts: 2712
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The work around is to create a Session Facade that queries the database for your list and builds the collection of Entities from the list. Of course, if this is called often then it begs the question, "Why use Entity Beans at all?"
Despite the fact that EJB 2.1 is focusing mainly on Web Services they are supposedly going to address this issue in EJB QL (along with date comparisons). That are also adding quite a bit more functionality to MDBs and including a timer service for EJBs as well. EJB 2.1 looks like is shaping up nicely and CMP may actually be very useful.
 
Paul Roubekas
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
With all due respect I disagree. When Java and J2EE�s biggest weak point is performance speed, one cannot afford to use workarounds that slow an application down further. I don�t have a study to site, but I think you would agree with me in saying that any SQL92 is faster at getting data then Session Bean methods sorting a Collection. There is no way marshalling data and un-marshalling all the field attributes of an object can be faster then a SQL SELECT looking at the values in one field for a Finder method to do a SQL Group By or SQL Order By. Until EJB-QL has 90%-95% of the functionality of SQL92 CMP J2EE will not live up to its potential. From what I am reading Group By and Having are not in the draft of EJB 2.1.
 
Chris Mathews
Ranch Hand
Posts: 2712
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am not saying that I am happy with the work around, that's what makes it a work around and not "The Way". If anyone has another solution for this problem then I would be happy to hear of it, I just don't see one.
You are experiencing some of the problems that have plagued Entity Beans from the start. It is no wonder that some developers have abandoned Entity Beans entirely.
 
Rick Hightower
Author
Ranch Hand
Posts: 350
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't agree. I find EJB 2.0 very useful. I have used WebLogic and Resin in production environments. I find them both very productive.
Combine it with XDoclet and it is very, very productive.
Just my 2 cents.

BTW At times we had to write some custom JDBC for reports and such, but not very often.
 
Chris Mathews
Ranch Hand
Posts: 2712
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am not saying that EJBs are not useful. I am just saying that there are glaring holes in the EJB 2.0 specification regarding CMP. Why do you think there is so much buzz around JDO? Everyone is looking for a better Entity Bean.
I agree that Session Beans and MDBs are extremely useful. Entity Beans... sometimes but not always.
 
Rick Hightower
Author
Ranch Hand
Posts: 350
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I am not saying that EJBs are not useful. I am just saying that there are glaring holes in the EJB 2.0 specification regarding CMP. Why do you think there is so much buzz around JDO? Everyone is looking for a better Entity Bean.

EJB 2.0 CMP is not perfect. I agree with that.
In fact if you search, I am sure you can find me complaining about it. But it is useful. I have used it in a production env. and it worked great.
Here are some interesting quotes about JDO vs. EJB CMP...
JDO vs. EJB CMP

Thoughts on JDO....
My opinion, EJB 2.0 CMP CMR is more mature than JDO. Most JDO implementation "don't fully implement the JDO spec. yet".... that said I think JDO will leap ahead of EJB in the near future...

I also think a future version of EJB 2.2 will merge EJB CMP CMR and JDO just like EJB 2.1 merged EJB and web services. There is really no point in having two frameworks that essentially accomplish the same thing. Therefore a later version of EJB will embrace JDO and build on top of it instead of replace it... Just my humble opinion. (note this is just a guess... i have not heard of any such activity)
At this point in time, if you want a portable persistence tier the best way to go is EJB CMP/CMR...

If you want to buy or sell components, you will most likely want a layer of persistence in your components to work cross-platform on application servers (for example, IBM WebSphere, BEA WebLogic, JBoss/Tomcat, etc.) and persistence storage systems (for example, Oracle, DB2, etc.). You do not have to write low-level Java Database Connectivity (JDBC) calls in your EJBs to add these features, a great reducer of time and complexity. Once you get the hang of CMP/CMR, it is faster to write entity beans using this technology, than using low-level JDBC inside of bean-managed persistence (BMP) beans.
What does this mean to you? Well, for starters, you do not have to write low-level JDBC calls and, you do not have to write code to manage relationships. It is all built into the EJB framework. Your interface to relationships is through the pervasive java.util.Collection and java.util.Set which most EJB developers are already familiar with. Very cool!
This additional feature includes support for JavaBeans component patterns for persistent fields, inside of the entity bean. Thus, instead of making your class variables public -- which has always felt strange to me -- you create get and set methods following the JavaBean technology standard naming pattern we all know and love.
I can't stress this point enough. Since EJB 2.0 containers will support the most common SQL databases (and other data stores as well), you can write components that work with many types of databases. This makes it easier to sell components that require persistent storage. For example, you can sell components that will work in an IT department that uses Oracle or a shop that uses DB2. Thus, instead of writing low-level JDBC calls using SQL native to a particular database, you will use EJB-QL to create finder and select methods, and describe relationships in deployment descriptors.
Simply put, CMP/CMR is the missing link in cross-platform component creation. CMP/CMR will spur the growth of the enterprise level component marketplace. In addition, CMP/CMR is easier to use then low-level JDBC calls. CMP/CMR corrects many of the foibles, and missing functionality of earlier versions of CMP. There are many persistence frameworks, none are available on as many application server platforms as EJB CMP/CMR!
Also, there is a significant increase in productivity by using select methods and EJB QL. Code that use to take 10, 20, 30 lines of code can be written in just a few by mastering EJB QL.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!