Delegate (most) type conversion to backends

[Leo Soto M.]

As discussed on the ​Mailing ​list and on IRC, some backends would be greatly simplified if they stop receiving string values for non-basic types, such as dates and decimal.

This patch delegates most of the get_db_prep_* logic of these fields to backend methods (named value_to_db_something where something is date, time, decimal, etc) It also implements get_db_prep_* for basic field types to avoid leaking string values.

For Jython/zxJDBC compatibility purposes, an special check was made on Field.get_db_prep_lookup and 'year' lookup. I was not able to understand it, so I choose to introduce as few modifications as possible there. It could be a good idea to delegate that logic to the backend too, but I think a second opinion is needed.

Finally, PhoneNumberField doesn't inherits from IntegerField anymore. There was no point on such inheritance, as phones are mapped to varchar fields on every backend. Not to mention that every method declared by IntegerField was overriden by PhoneNumberField.

This was tested against mysql, postgresql, oracle and sqlite3, and didn't broke anything (that wasn't already broken on trunk, at least).

[Adam Vandenberg]

Patch against revision 7818

[anonymous]

Setting 1.0beta milestone, as Jython (and others Python VM such as PyPy) compatibility is on the 1.0 maybe list.

[Jacob]

This looks good at first glance. There's some commented-out code and # XXX comments that need to be removed/resolved; I'll read the patch in more detail a bit later and leave more feedback then.

In the meantime, Leo: can you post a summary of this ticket and the change to django-dev and make sure nobody sees problems with the general approach? Now that you have a working patch a final discussion of weather we should be doing this needs to happen real quick.

[Leo Soto M.]

Replying to jacob:

This looks good at first glance. There's some commented-out code and # XXX comments that need to be removed/resolved;

Oh. Well, the commented out code was accidental. But the #XXXs where left on purpose, to make sure that the question doesn't remain unanswered when/if the commit occurs.

[Leo Soto M.]

Updated to current trunk. Also refactors year lookup code.

[Leo Soto M.]

Hmm. I discovered that this refactor breaks _get_next_or_previous_by_FIELD on DateTime and Time fields. That's because Model._get_next_or_previous_by_FIELD always coerces the "current" value as string, then datetimes (and times) are converted to a string with usecs that can't be parsed later by DateTimeField.to_python.

So I'm going to improve the to_python method on both DateTimeField and TimeField.

[Leo Soto M.]

Also fixes to_python on Time and DateTime fields. Includes tests for this addition.

[Leo Soto M.]

Avoid failing test if the backend doesn't support usecs

[Leo Soto M.]

Yet another patch update. This time, I've also removed some code duplication of almost all get_db_prep_save/get_db_prep_lookup methods, as discussed on ​http://groups.google.com/group/django-developers/browse_thread/thread/29f95436ed433d85.

[Leo Soto M.]

Updated to svn r8011

[Leo Soto M.]

BTW, after the get_db_prep_value addition, I included changes to the documentation on the patch. I'm sure that it needs many changes as my English is not on par with the quality of Django docs.

[Sean Legassick]

Fixes for TimeField.to_python and extra tests

[Malcolm Tredinnick]

I started reviewing this last night. Will get it committed today or tomorrow.

[Malcolm Tredinnick]

(In [8131]) Fixed #7560 -- Moved a lot of the value conversion preparation for
loading/saving interactions with the databases into django.db.backend. This
helps external db backend writers and removes a bunch of database-specific
if-tests in django.db.models.fields.

Great work from Leo Soto.

[Jacob]

Milestone 1.0 beta deleted