option to ignore filters with null values

[GoogleCodeExporter]

** Use case:

I want to make a simple DAO method:
public List<Person> findByName(String first, String last);

I could implement it simply like this:
public List<Person> findByName(String first, String last) {
    return search(new Search()
                    .addFilterEqual("firstName", first)
                    .addFilterEqual("lastName", last));
}

But what if I want this method to ignore one of the names if it is null? 
Then I would have to write it:
public List<Person> findByName(String first, String last) {
    Search s = new Search();
    if (first != null)
        s.addFilterEqual("firstName", first);
    if (last != null)
        s.addFilterEqual("lastName", last);

    return search(s);
}

** Proposal:

Add an optional "ignoreIfNull" parameter on each addFilter... method, and 
add a default value for the whole Search. If the property is unspecified 
for a given filter it uses the property from the search. The property 
defaults to false for a new search. It can be specified for the search in a 
setter or an optional constructor parameter.

Then the method could be something like this:
public List<Person> findByName(String first, String last) {
    return search(new Search(true) //<-- ignoreIfNull specified for search
                    .addFilterEqual("firstName", first)
                    .addFilterEqual("lastName", last));
}

or this:
public List<Person> findByName(String first, String last) {
    return search(new Search()
                             //ignoreIfNull specified  for filter 
                    .addFilterEqual("firstName", first, true)
                    .addFilterEqual("lastName", last, true));
}

Original issue reported on code.google.com by dwolvert on 23 Dec 2008 at 10:04

[GoogleCodeExporter]

What about addFilter... methods that take var-args. we can't add a boolean 
parameter 
at the end. It may be okay not to use this parameter on these types of filters.

The types are currently:
IN, NOT IN, AND, OR

Original comment by dwolvert on 23 Dec 2008 at 10:06

[GoogleCodeExporter]

Re: What about addFilter... methods

It's definitely okay with AND and OR. They always have this ignore if no values 
behavior.

With IN and NOT_IN, it might make sense to have these method signatures:
.addFilterIn(String prop, Collection value)
.addFilterIn(String prop, Collection value, ignoreIfNone)
.addFilterIn(String prop, Object[] value)
.addFilterIn(String prop, Object[] value, ignoreIfNone)
.addFilterIn(String prop, Collection value)
.addFilterIn(String prop, Object... value)

Because when using the varargs param, the developer is explicitly indicating the
values, so he/she will know whether there will be an empty set of values.

These method signatures would not compile, however, because (String prop, 
Object[] 
value) and (String prop, Object... value) have the same erasure. So perhaps we 
can 
change
.addFilterIn(String prop, Object... value)
to
.addFilterIn(String prop, Object firstValue, Object... otherValues)

It doesn't exactly match what we're going for, but it works nearly the same way.

Original comment by dwolvert on 2 Jan 2009 at 3:48

[GoogleCodeExporter]

All this is going down the wrong trail!! For every operator but equals, null 
values 
will generate errors. There is never a case when we would not want to ignore 
nulls 
for all of these operators.

For the equals operator, we currently deal with a null value by using an SQL IS 
NULL 
operator. This may or may not be intuitive to users.

So let's just implement it so that any filter will be ignored if it has a null 
value. 
And then add IS_NULL and IS_NOT_NULL operators to replace the lost 
functionality from  
limiting the EQUALS operator. This way our operators will be consistent with 
SQL, 
which means fewer surprises for users.

Original comment by dwolvert on 2 Jan 2009 at 9:05

[GoogleCodeExporter]

Changes made according to comment 3. Will be included in release 0.4.1.

Original comment by dwolvert on 5 Jan 2009 at 2:50

• Changed state: Verified