option to ignore filters with null values about hibernate-generic-dao

[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