'Between' functions on paths should be nullsafe

[Lieven Doclo]

Currently, if you have a for example a numberpath, calling path.between(x, y) with one of the bounds being null (which for example can happens if those bounds are omitted by the user, it would be convenient if the between method would delegate to the goe or loe functions when one of the arguments is null.
So that:
path.between(x, null) => path.goe(x)
path.between(null, y) => path.loe(y)

Taken this even further, predicates (except for the isnull and isnotnull predicates) should ignore null passed argument, effectively return a dummy predicate (for example, an empty BooleanBuilder).

[Timo Westkämper (timo-westkamper)]

Your proposition for between looks good, but I hesitate to take this further, because allowing null for semantically non-null parameters would mask lots of bugs in programs. Querydsl should be safe to use.

[Vesa Marttila (ponzao)]

I agree with Timo. Accepting nulls as arguments will end up biting some people in the behind. The between case might be ok because it seems to be quite common behavior (at least Lucene works like this).

[Lieven Doclo (lieven-doclo-jintec)]

Then perhaps you should provide null-safe variants of the methods. My case in point is when you're using filter objects. When you have a filter object with 10+ filter criteria this would result in at least 10 if-structures checking on null (=when that filter field is not used). Using null-safe variants would imply that the predicate is only applied when the value passed to that predicate is not null.
Currently, I've solved the issue by implementing a static utility method:

query.from(QProduct.product).where(Predicates.applyIfNotNull(filter.getProductName(), QProduct.product.name.eq(filter.getProductName())));

However, this would be nicer:

query.from(QProduct.product).where(QProduct.product.name.nullSafeEq(filter.getProductName()))

[Timo Westkämper (timo-westkamper)]

Released in 2.2.0.beta5