On Tue, May 27, 2008 at 2:50 PM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > On Mon, May 26, 2008 at 11:26 PM, Leo Soto M. <[EMAIL PROTECTED]> wrote: > > dates, times, and datetimes are converted to string _before_ being > > passed to the backend. > > Oops :) > > > b) Pass the backend (or its DatabaseOperations) to > > Field.get_db_prep_save. We could then add a > > DatabaseOperation.to_db_date(value) method, which would be called from > > get_db_prep_save. In other words, date (and friends) conversion would > > be delegated to the backend. > > This is probably the better solution, though you don't need to pass > the backend into ``Field.get_db_prep_save`` since ``db_prep_save`` can > get at the backend through ``django.db.connection.backend``.
I went through this path, but found a few problems I think may be worth to point out here: - It seems that the type of the value passed to `get_db_prep_*` isn't always the obvious python data type associated with the field. For example, `DateField.get_db_prep_save` and `DateField.get_db_prep_lookup` uses duck typing to support datetime.date and string as the type of `value`. My first reaction was to use self.to_python(value) to ensure that I have a date object before calling the proposed `DatabaseOperation.value_to_db_date()`. But later remembered that `Field.to_python` was meant for DB -> Python conversion and not the other way around. - If I keep following the same path, I'll have to add a DatabaseOperation.value_to_db_ipaddr() too. On JDBC, PostgreSQL is not happy with plain string values (I think I'll need to add a explicit cast there) - The management of the `lookup_type` in `Field.get_db_prep_lookup` looks weird to me. I don't get why the `year` lookup need special treatment and the `month` lookup doesn't. Also, in DateField, DateTimeField and TimeField, the `range` lookup have the special treatment aimed at returning a list instead of a single value, but the `in` lookup type doesn't. I'm sure there is a reason for this odd behavior, but I can't see it. - From tests cases I'm seeing that, under some circumstances, strings are passed to the backend as the value of parameters which, in the database, are of numerical types. Numbers (0, 1) instead of booleans too. Is this an intended behavior? -- Leo Soto M. http://blog.leosoto.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
