On Sat, 2007-11-03 at 21:40 -0500, Tim Chase wrote: [...] > I know it's generally bad form to change > configuration settings between testing/development/production, > but such isolated changes make appropriate functionality > available when needed and remove it when a proven solution works.
Well, I don't agree with this statement. :-) It's quite common to have different requirements for development and testing and final production installations. So portions of your settings might very well be conditional on the context. > > >> I'd also like to be able to do comparisons of these > >> PartialDateFields on the DB side of things, having them > >> translated to their appropriate corresponding code (for the __lt, > >> __gt, __between, __range, etc bits). Thus, it would be nice to > >> be able to write code like > >> > >> foos = Foo.objects.filter(dob__gt = date(1955,4,1)) > > > > I'm not entirely sure what you mean here, since you give your preferred > > syntax without describing what it does. So guessing a bit... > > > > As part of constructing the query, the get_db_prep_lookup() method on > > each Field class is called to convert the value you give into the right > > format for SQL. Have a look at how that works in > > django/db/models/fields/__init__.py (there's a default Field version and > > some subclasses override it). > > > > What you cannot do easily is convert something like dob__gt into > > *multiple* pieces of SQL. In the future (after queryset-refactor is > > merged) you will be able to write something that looks like a Q object > > and has access to the full SQL query for making additions like that, but > > it will still require writing a bit of code yourself (this is a far, far > > edge case, after all). Not impossible, though. > > Yes, you've divined my intent despite my opaque one-liner. Since > the "dob" field is actually comprised of the four parts (month, > day, min_year, max_year), the above would unpack to something like > > WHERE dob_max_year > 1955 OR > (dob_max_year = 1955 AND > (dob_month > 4 OR > (dob_month = 4 AND dob_day > 1) > ) > ) > > with the __lt variant using dob_min_year instead of max_year. > Fortunately, SQL is a bit smarter about null-comparisons than > Python so the above should work regardless of null column-data > (as you need progressively more detailed information in that > particular order). > > I've looked over the get_db_prep_lookup() as well as the > promising-sounding get_where_clause() in db.models.query but > neither looks like what I want to be able to do. > > I may go the route of a custom set of managers, but was hoping to > avoid doing something on a per-model basis, and instead have the > field smart enough to know how to mung its own SQL. If I'm > feeling really daring, might it make sense to refactor some of > this functionality into the Field class to allow for it to be > overridden by subclasses just such as this? Probably a move in the wrong direction generally. The idea is to move most of the SQL fragments out of core code. That's the direction queryset-refactor is going in. Specialised cases will need some SQL in their Field subclasses, but for core code that should be mostly unnecessary and not worth adding (it's extra overhead that gets called every single time). For custom fields, there will be some hooks for things like creating their own retrieval SQL (everything that's there now, plus a lookup hook that is needed for things like GIS fields), but I don't see a massive use-case for multi-part insertion like you're after, so that might be some ways down the track (after queryset-refactor is merged, certainly). As I mentioned, probably the best way to do this in the post-queryset-refactor future will be something like a Q-object that knows how to work with your special field. That will have full access to the query as it is constructed, so will be able to do multi-part insertions. > Currently the > get_where_clause() is simply a module-level function that seems > to only be called from one place in that query.py file, and only > used where there's already a subclass of the Field in context. > I've "svn up"'ed my trunk code and will try my hand at a hack > this weekend. The new code is going to look nothing like that (because it doesn't cover a lot of cases we need to be able to handle), so whatever you do here is just for your own use. So long as you understand that, go for it. Alternatively, work out a similar design for the queryset-refactor branch (although realise it's not nearly ready for production use yet). Regards, Malcolm -- No one is listening until you make a mistake. http://www.pointy-stick.com/blog/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~----------~----~----~----~------~----~------~--~---
