DateField's __range and __in lookups against expressions produce invalid values on SQLite.

[Simon Charette]

#22288 (4f138fe5a496a81115c4fba6615a517fc62c3b17) only partially addressed the issue of iterable right-hand-side lookups (__range and __in) by adapting Oracle's and SQLite operation modules to special case the adaptation of datetime and time value while missing that date values are still converted to string.

This causes queries of the form

Person.objects.filter(
    dob__between=(F("dob"), F("dob"))
)

To be turned into

SELECT * FROM person WHERE dob BETWEEN "Col('dob')" AND "Col('dob')"

I believe the fundamental flaw in 4f138fe5a496a81115c4fba6615a517fc62c3b17 is that expressions (hasattr(obj, "resolve_expression")) should never be passed to Field.get_db_prep_value in the first place during the Lookup's right-hand-side processing phase just like they are not passed to Field.get_prep_value ​during the preparation phase.

Initially discovered on ​the forum by Joel Feiner.

[Mariusz Felisiak <felisiak.mariusz@…>]

In 0fcee16:

Fixed #35111 -- Fixed compilation of DateField in/range rhs on SQLite and MySQL.

Also removed tests that ensured that adapt_(date)timefield backend
operations where able to deal with expressions when it's not the case
for any other adapt methods.

[Claude Paroz]

Does this has any effect on #25591?

[Simon Charette]

From a quick look I don't think it does Claude as the logic changed here only relates to lookups. In other words, RangeField and RangeLookup are completely different beasts.

[Claude Paroz]

OK, thanks Simon and sorry for the noise.