<vendor>
The Inprise Application Server can help you here by allowing you to
use only one finder to cater for the 3 combinations in your example.
Of course the more parameters you add to the criteria the more
complex
the SQL statement will get.
<finder>
<method-signature>findByCriteria(Criteria c)</method-signature>
<where-clause>((:c.age is null) or (:c.age = age)) and
((:c.name is null) or (:c.name = name))
</where-clause>
<load-state>True</load-state>
</finder>
</vendor>
William Louth
Inprise Europe
-----Original Message-----
From: Wade Catlyn [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 09, 2000 2:20 PM
To: [EMAIL PROTECTED]
Subject: Re: Dynamic finder method with CMP
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 ? )
I am wary of utilising a technology that assumes a specific means of
persistence (such as RDBMS that Percolator does). 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 ?
thanks,
Wade Catlyn
Peter Antman wrote:
>
> Personally I think this is one of the dark corners of the EJB
> specification. Not so much because of the difference between BMP and
> CMP beans, and not because of the underspecification of how to define
> findByXXX in CMP beans, but because these finders don't belong in the
> bean definition in the first place.
>
> To me Entity Beans are first and foremost a way to represent data in
> an objectoriented way, with the possibility to ad some small amount of
> bussiness logic to it. But if there are much bussiness logic required
> this should be placed in another layer, a bussines layer and not in
> the data layer where the enity beans logically belongs.
>
> This becomes really acute when you have your data in a relational
> database. As you hint, there are allways a lot of different ways to
> search i an rdbms. Actually we will get a permutaion for all
> attributes, and for every possible way of specifying the search critera
> for each attribute. Say we have four attributes, just beginning to
> list the possible combination is tidious:
>
> WHERE name='xx'
> WHERE name='xx' AND sex='yy'
> WHERE name='xx' AND sex='yy' and age=ii
> WHERE name='xx' AND sex='yy' and age=ii and interest='hh'
>
> And then we could begin to use some of the strength in SQL:
>
> WHERE name='xx' AND sex='yy' and age>ii and interest=like'%hh%'
>
> This could go on and on, almost forever. Ad some more attributes and
> it is clear that you will never want to implement finders for all
> these combinations.
>
> How to solve it? In Percolator - the open source EJB brewers toolkit
> (http://www.percolator.org)
> we have solved it by creating an axternal EJB service called EJB Query
> Sevice (EQS). If you want to create advanced querys over an
> information domain and get the information represented as entity beans
> you use EQS to get it.
>
> EQS is usable today, but it is still not debugged and tested
> enough. It also still uses SQL to do the querys. An OQL subset will be
> developed when we have the time.
>
> How would an EQS query look like?
>
> initial = getInitialContext();
> Object o =
> initial.lookup("org.backsource.eqs.impl.QueryManagerHome");
> QueryManagerHome home =
(QueryManagerHome)PortableRemoteObject.narrow(o,
>
org.backsource.eqs.impl.QueryManagerHome.class);
>
> // Test collection api, this will fetch and send all entity refs
> //at once
> QueryRemote query = manager.createEntityQuery("UserData", "SELECT
> DATAID FROM Person WHERE USERI=1");
> RemoteCollection coll = new RemoteCollection();
> query.find( coll );
> List list = coll.getList();
> Iterator i = list.iterator();
> while( i.hasNext() ) {
> UserDataEntity p = (UserDataEntity)i.next();
> System.out.println( p.getDataGroup() );
> System.out.println( p.getDataKey() );
> }
> query.remove();
>
> // Test iterator api, this will fetch one ref at a time
> QueryRemote query = manager.createEntityQuery("Person", " SELECT
personID FROM Person WHERE adress='Tideliusgatan 60'");
> ClientIterator it = new ClientIterator();
> query.find( it );
> while( it.hasNext() ) {
> PersonRemote p = (PersonRemote)it.next();
> System.out.println( p.getName() );
> }
> query.remove();
>
> In Percolator your generated beans will also be able to bet fetched
> as a whole over the wire through so calles ValueHolders. It is
> possible to them directly from the Query (it is also possible to use them
to
> instantiate a client proxy that will the communicate with the backend
> entity beans).
>
> Percolator currently support Weblogic 5.1, but will soon also support
> the open source servers Jboss and Jonas. (It is quite easy to make it
> support any type of EJB server).
>
> Excpect a new beta release soon. Unfortunately the EQS part will not
> be finnished before the summer.
>
> Peter Antman
>
> Wade Catlyn wrote:
> >Hi folks,
> >
> >I wish to implement an entity bean that has a findBy method whose search
> >criteria is specified dynamically. This would be useful for operations
> >where a user can specify what criteria he wishes to search by. (e.g an
> >html form with several fields such as name, age, address, date... etc,
> >and the query would be composed using only the fields which the user
> >selects).
> >
> >This can be easily done using bean managed persistence by having a
> >method of the form: findByCriteria(SearchCriteria sc)
> >where the desired query would be composed using the information
> >extracted from the SearchCriteria object.
> >
> >However this would not be possible if container managed persistence is
> >used.
> >
> >Does anyone have any suggestions on how this kind on functionality could
> >be implemented without having to give up the advanteges of CMP ?
> >
> >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".
===========================================================================
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".
===========================================================================
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".
