On Thu, 2007-03-15 at 16:42 -0500, Jeremy Dunck wrote: > On 2/25/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > > > I noticed today that a new GIS branch has been created, which includes a > > goal to develop a custom QuerySet-derivative. > ... > > I don't know of any announced plans/wishes that affect QuerySets that > > would become more difficult under this change, so please sing out if you > > know of any. > > We are a bit further along on the GIS work. If possible, I'd like to > avoid becoming dependent on the QuerySet refactoring, but I also don't > want to make it any harder. > > So far, the only pain is in the fact that all lookup types share the > same namespace, but may have different semantics based on the field > type. For example, text "contains" is very different than GIS > "contains". > > There are two places so far that this causes trouble. > > django.db.query.parse_lookup uses a static list of mappings (... > lookup_type not in QUERY_TERMS...) in order to default the lookup type > to "exact". > > django.db.query.get_where_clause does the wrong thing for GIS contains. ;-) > > Both could be addressed by allowing lookup_type semantics to differ > depending on what Field type is being used. > > I think it'd be nice to move .get_where_clause to > django.db.models.fields.Field and subclasses. When a class ois first > constructed (or the first time .contribute_to_class is called) it > could register a mapping for a given lookup_type. > > from django.db.models.query import register_lookup_types > > class Field(...): > ... > > def __init__(self,...): > if Field.creation_counter == 0: > register_lookup_types(self.__class__, ['contains', 'ilike',...]) > > def get_where_clause(lookup_type, table_prefix, field_name, value): > ... > get_where_clause = classmethod(get_where_clause) > > Then .query.get_where_clause would change to just locate and call the > related field.get_where_clause. > > I think this change could be made (on the gis branch) without too much > trouble. > > I don't think this harms the QS refactoring discussion, but wanted to > make sure it's OK before proceeding in this direction.
I have a dim memory that there's a trick required if you do this and I'm trying to remember what the problem was. It's not coming forwards at the moment... :-( Looking at the code I've written, I think the only potential problem tnhat jumps out is that constructing some of these things is database-engine specific (some of the text matching options, potentially), so having access to the db backend is necessary. But I'll have a look at whether I can just transplant them easily to the Field class. As a design issue, it's a little leaky in that Field classes are currently unaware of any database interactions (see next paragraph for why I like this). However, you are creating something that is fairly tightly tied to the backend, so it's hard not to have leaky encapsulation in your case. Tough to see how you could do it otherwise without also dragging the rest along (well, one way would be to conditionally call the field if it had a particular method, but that feels icky in some ways, too). I would probably call out to another function somewhere to do the real registration, since I have (pipe?) dreams of wanting to be able to replace the database work with another backend (e.g. RDF-based, SQLAlchemy, bdb) easily. But that's a minor issue of where to put the actual code and whether to have a function call and it's way down the track. As an aside on the sample you jotted down: any big reason why you want it to be a class method here? It doesn't seem to gain a lot in the usage, as far as I can see, since you're going to be running through Field *instances* when you are constructing the query in any case and I don't think we need to access class-level variables in these methods, do we? [I know why you might want to do it from a "OO purity" stand point, since it is tied to the class more than the specific instantiation, but if it doesn't hurt to access it through the instance it's just visual over-kill. That's what I'm wondering about.] Having thought about it for a whole 10 minutes, I'd say try that path out and if I think of anything, I'll sing out and help you port it. Cheers, 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 -~----------~----~----~----~------~----~------~--~---
