>
> I'm beginning to realize that EJB 2.0 specification has a
> serious limitation.
> It's the EJB QL.
>
> Take for example a simple problem: How to create a finder or
> select method
> that would return a set of entities that a user specifies by
> for example 4
> different attributes where each of them could be missing
> (null) and would
> therefore not account into the query result? Create 16
> different finders for
> every combination of 4 attributes and a switch statement?
> What if there were
> 10 different attributes? Create 1024 different finders?
>
> Another example: the "LIKE pattern_value" construct where
> "pattern_value" can
> only be a literal value and not a parameter. I understand that this
> limitation arises from the similar limitation in the SQL from
> which EJB QL
> was derived so that mapping from EJB QL to SQL is easy...
Yep, it is very limited.
> What is missing from the EJB 2.0 spec and would greatly improve the
> "fullness" of the specification is execution of EJB QL
> queries that are
> composed programatically at runtime.
>
> So what am I doing on this list? Read on...
>
> As I understand it, the EJB 2.0 spec has provided app server
> vendors with a
> possibility to create proprietary extensions to finder/select method
> processing with the following (taken from the ejb-jar_2_0.dtd):
>
> "Queries that are expressible in EJB QL must use the ejb-ql element to
> specify the query. If a query is not expressible in EJB QL, the
> description element should be used to describe the semantics of the
> query and the ejb-ql element should be empty."
>
> ...and the interpretation of the description element is up to
> the container
> provider...
I didn't know this.
> I'm proposing (and I believe that it would not be hard to
> implement in JBoss)
> something like the following:
>
> 1. bosscmp-jdbc.xml: add optional <ejb-ql-composer-class>
> element as a child
> of <entity> elements:
>
> <entity id="...">
> ...
>
> <ejb-ql-composer-class>the.composer.Class</ejb-ql-composer-class>
> ...
> </entity>
>
> the.composer.Class would implement the following interface:
>
> public interface EjbQlComposer {
> // return the EJB QL query string
> public String composeEjbQlQuery(String
> description, Object[] parameters)
> throws FinderException;
> }
>
> Before executing any finder/select method with an empty
> <ejb-ql/> element in
> the particular entity an instance of the specified
> <ejb-ql-composer-class>
> would be created, the composeEjbQlQuery method called with
> the <description>
> element content from the <query> being executed and the
> parameters to the
> finder/select method passed in Object[] array. The method
> would compose and
> return a string consisting of EJB QL query which the
> container would compile
> and execute.
>
> What do you think? Would that be feasible? I'm interested in
> implementing
> this and contributing to JBoss...
>
> Peter
So basically you want dynamic EJB-QL. This id possible, but would be slow.
The current EJB-QL engine was not designed to be fast, as all parsing is
done at startup. Eventually, I plan on rewriting.
To solve this type of problem, I plan on supporting dynamic-sql. Which
would allow you to do this type of thing, but would require you to know the
database mapping.
-dain
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
