On Fri, Jul 31, 2009 at 01:01, Alex Gaynor <alex.gay...@gmail.com> wrote: > > Russ: My primary concern with adding a new method is that it will > signficantly complicate the implementation, particularly it pollutes > the implementation, rather than putting the onus on calling code, > which I've found makes it a very clean transition. In total there are > under a dozen places within Django that call these methods, and > eventual deprecation/removal would be fairly easy. I haven't actually > found a usecase for user code calling into get_db_prep_* or db_type. > I should also note that I've found a total of 2-3 instances of user > code callign these methods on Django field classes in all of google > code search, indeed far fewer than the number of places these methods > are implemented. So I do still believe that my original proposal is > the least invasive, and reasonably backwards compatible (it's worth > remembering just be the nature of this discussing we're already > talking about a veyr minority of users who have custom field classes > with these methods). > > Alex >
I am probably not seeing why this is not possible, but what about: get_prep_db_value(self, value, connection=default_connection) ? Wouldn't that accepts both current and new parameters? Just my 2c, TiNo --~--~---------~--~----~------------~-------~--~----~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
