On Tue, 2008-07-15 at 11:49 -0400, Leo Soto M. wrote: > After fixing some corner cases of #7560[1], and realizing that it is > too easy to write a wrong get_db_prep_lookup method (example: > #7448[2]), I have reached the conclusion that there is no reason to > have *two* methods for doing the python -> db conversion > (``get_db_prep_save`` and ``get_db_prep_lookup``). Not for most of the > fields, at least.
I think it will take me a few days to think through all the implications here. However, I suspect the least intrusive change is to keep db_prep_lookup and db_prep_save, but have them call a common method (which could be called db_prep_value if you like). I can think of some slightly twisted cases where lookup and insert values will be different. For example, if I make a "month" field type, I would use an underlying date field column and the insert would be a full-fledged date value, whilst the lookup would be a call to a date extraction function in SQL. There quite possibly exist some legitimate cases like this as well (GIS stuff springs to mind as an area to look, for example). So, sharing common code would be good. Forcing everything to use the same code would probably come back and bite us. I think we're too close to an irreversible boundary for the API to make that type of change now. It often takes a few months, or longer, for all the corner cases to fall out. Thus, I'd keep the current API for the boundary between fields and the backends, but factor out the common bits more explicitly. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
