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".
