Design problem involving Wildcards and EJB-QL.

Question

Could someone tell me if this is possible? (my syntax might be a bit off, but bear with me. It's the design I'm interested in, not the exact syntax)
signature="java.util.Collection findByFullMonty (java.lang.Float price, java.lang.Integer bedrooms... "*snip*
query="SELECT OBJECT(o) FROM Houses o  WHERE ((o.price =?1) AND (o.bedrooms= ?2) AND ... "*snip*I'd like to be able to use this query with wildcards as default values in a fashion similiar to this:
Float price = ??  ;//This is where i'm unsure, what is a valid wildcard for a Float?
Integer bedrooms = ??; // same here for Integer....
String realtorName = "*"; //i think this is valid wildcard for strings
*snip*
//if price supplied set price to input value
if (myObject.getPrice() != null){
    price = myObject.getPrice();
//if bedrooms supplied set bedrooms to input value
if (myObject.getBedrooms()!= null){
    bedrooms = myObject.getBedrooms();
//always use this finder using wild cards  unless a parameter is supplied
Collection c = findByFullMonty (price, bedrooms,  realtorName, *snip*); What i'm tyring to achieve is a single query that will work no matter how many of the input paramaters are supplied. Any supplied parameters are used, and those that are not supplied will use wildcard instead. I don't want to make a seperate query for every possible permutaion of supplied input parameters. Can this be done? If so, am I even close or out in left field? Is there a design pattern I should look into for this problem?
Thanks for any help guys!
(sorry for the cross-post, i didn't realize this was the approprate place until afterwards)

Answer 1

Yes, that makes sense, but the EJB-QL statements and finder methods in the home interface have to be defined at deployment time, correct? Once it is deployed, I can't dynamically create the EJB-QL statements and finder methods that are needed. That's the major hurdle I have right now.
Populating a big 'catch-all' query with wild cards and replacing them with supplied literal values is the only way I could think of to accomplish this dynamically. In my current work around I set a flag for each piece of data supplied. I then decide which (pre-defined) query is needed based on the supplied criteria flags. The problem is, I now have to have 2^n (n = number of possible input parameters) permutaions for the possible queries. For example: say i have: price, bedrooms and bathrooms. I'd need queries for the following cases:
1 price supplied only
2 bedrooms supplied only
3 bathrooms supplied only
4 price and bedrooms
5 price and bathrooms
6 bedrooms and bathrooms
7 price, bedrooms, bathrooms
8 nothing supplied (return everything)
Obviously this is going to break down really fast as the number of input parameters climbs.
Should I look at using some kind of JDBC code directly to build a query as I go? It seems like I am either approaching this the wrong way or missing something really obvious.