On Tue, 2009-04-21 at 16:36 -0400, Alex Gaynor wrote: > > > On Tue, Apr 21, 2009 at 4:29 PM, Malcolm Tredinnick > <malc...@pointy-stick.com> wrote: > > On Tue, 2009-04-21 at 15:46 -0400, Alex Gaynor wrote: > > > > > > On Tue, Apr 21, 2009 at 3:14 PM, Malcolm Tredinnick > > <malc...@pointy-stick.com> wrote: > > > [...] > > > > Postponing any real decision making (at the code > level -- I'm > > not > > talking about the human level) makes things a lot > more > > complicated > > internally and the cod we're talking about here is > already > > complicated > > enough. Make as many decisions as soon as you can > and postpone > > those you > > can't -- don't attempt to postpone everything in an > attempt to > > achieve > > some kind of cosmetic consistency. > > > > I'm not looking to put off decisions in general, just the > pressure of > > trying to come up with the right answers while > simultaneously dealing > > with the 1.1 release > > > You've misunderstood what I was meaning. Your response is the > human side > (as in "decisions made by humans"). I was talking about the > *code* > making decisions. That is, in the code, convert things to > their final > data format as early as possible, but no earlier and, > preferably, don't > postpone doing everywhere (your option 2 and option 3) that > just because > *some* things need to be postponed. > > > > Sigh, that's just a reading comprehension fail. I've done a complete > review of the codebase and I think I've identified all the places we > test against Query.connection, and none of them appear particularly > overwhelming: > * ``Query.add_aggregate`` > * ``Query.set_group_by`` > * ``DateQuery.add_date_select`` > * ``Field.get_db_prep_lookup`` > * ``DateField.get_db_prep_value`` > * ``DateTimeField.get_db_prep_value`` > * ``DecimalField.get_db_prep_save`` > * ``TimeField.get_db_prep_value``
All the db_prep_* calls are the places that will need an holistic workaround. They are there (in Where.add(), particularly) to avoid pickling problems, partly. Also to save time -- via removing the need for a bunch of deepcopying or needing to write out own complex Where.__deepcopy__ -- when cloning querysets. In a nutshell, we try to avoid storing copies of Field-derived objects, since they can essentially be arbitrarily complex. Out of the box, related fields are a good example of that. Even further out, complex fields can be even worse. So finding a way to not have to store arbitrary Field-like classes whilst still retaining some independence might require some thinking and a discussion here when you get to that point a ways down the track. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
