Hi again, back from the weekend.
Wade Catlyn wrote:
>I was also thinking of a limited scenario where a bean could have say
>three container-managed finders , findByName(String name), findByAge(int
>age) and findByNameAndAge(String name,int age). Along with these there
>would be one bean-managed finder, searchCriteria(SearchCriteria sc)
>which would just delegate to the appropriate container-managed finder.
>So searchByCriteria would look something like :
>PrimaryKey searchByCriteria(SearchCriteria sc)
>{
> if (sc contains name only)
> {
> return findByName(sc.getName())
> }
> else if (sc contains age only)
> {
> return findByAge(sc.getAge());
> }
> else
> {
> return findByNameAndAge(sc.getName(), sc.getAge());
> }
>}
>
>However, as you indicate, an approach like this quickly becomes
>infeasible because of the combinatorial explosion of finder methods
>needed as the number of search criteria increases. This approach would
>also be impossible because the EJB 1.1 spec does not allow bean-managed
>finders in a container-mangaged bean (am i correct on this ? )
The generall aproch would be to implement a manager for the Enity bean as
a
stateless session bean I guess, and make it a go-between. You could then
implement any delegating methods in it, even methods that looks up in the
database directly.
>
>
>I am wary of utilising a technology that assumes a specific means of
>persistence (such as RDBMS that Percolator does).
I can't say that you should use EQS is Percolator, what I tried to discuss
was
a generall problem in the specification of Entity Beans, which EQS tries
to
solve in a generic way (something in the line of the Corba Query
Service).
But I also have to say that EQS in Percolator (http://www.percolator.org)
is *not* tied to a specific means of persistence. It is an API, that
defines
two types of Query langugages (SQL and OQL, and with a third planned,
"Query By Template"). It has a default implementation wich work againts a
backen throuhh an internal API. Currently there are only one backend
implemented, for an RDBMS, and that backend still only supports SQL.
>Looking at the draft
>EJB 2.0 spec though, I think that the EJB query languange (EQL) would go
>a great way to solve that problem. From my reading of the spec however,
>it seems you would encounter the same problem of having to specify a
>static search criteria.
>
>Shouldn't it be possible to define a find method which dynamically
>creates an EQL statement, and then passes it on to the container to
>handle appropriately ?
This would of cource be practical, at least to have a commonly defined
query
language (I hav'nt had the time to look at the spec so I don't know if
EQL really is a query language yet). But even if the query was to
be dynamic it would still be tied to a particular bean through the beans
home,
as to the specification of finders. But what does that mean? For EQL to
be able to map a query against a specific persistence mechanism is must
know
how to translate the EQS to SQL or OQL or some other native query language
for
the peristence mechanism. But beeing tied to one bean means that is
basically
will only have access to meta data for that particular bean (i.e its
mapping
from attributes to data base collumns).
As I already hinted, if you have a complex information domain modelled as
Entity beans, you will, sooner or later, want to be able to construct
advanced
queries over that domain, and you will want to be able to query also over
relationships. You have a Person who has Adresses, for example. You will
some time want to get only the Perssons who have an Adress like something,
eg:
select p.personid from person p, adress a where p.personid = a.personid
and
adress.street like '%SOMENAME%'
or in OQL syntax (I think)
select p from Person p where p.adress like '%SOMENAME%'
To do this mapping, the container for the Person bean would also need to
know the meta data for the Adress bean. If this is even possible in the
current
specification I can bett my pant on that this will lead to vendor specific
mapping definitions.
In EQS we have solved this by saying that a Query Service is set up for a
specific information domain; and EQS will have access to all the needed
metadata for that domain to be able to map al types of relational queries.
I think this is a reasonable approach. Otherwise you are left at:
1. Implement every finder by hand, meaning your entity beans will be
constantly
changed in any dynamic environment.
2. Implemetn a manager with some kind of query capability, meaning you
will
have to support you own query logic and service.
3. Shose a vendor wich have some kind of proprietary solution, wich means
you
will get locked in to that vendor.
4. Use EQS in Percolator.
The latter is however currently not recomended if you are not willing to
help
in developing EQS, since it is not ready for prime time yet (we will put
in
resources in august). What is good with it is that it is cross-vendor,
that
its open source and that I think it solves (at least for now) a problem
with querys and Entity beans.
Greetings
Peter
>thanks,
>Wade Catlyn
------------------------------------------------------------
Peter Antman Technology in Media, Box 34105 100 26 Stockholm
Systems Architect WWW: http://www.tim.se
Email: [EMAIL PROTECTED] WWW: http://www.backsource.org
Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942
------------------------------------------------------------
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
