I thought Django already did option 1. If it doesn't, why not? What are the possible edge cases? Using a date field named "date" as a foreign key to another model that also contains a "date" field?
On May 10, 1:47 am, Ulrich Petri <[email protected]> wrote: > Currently there are at least 4 open tickets [1-4] that propose the addition > of new lookup types. Two of them [1,2] are in DDN because of backward > compatibility concerns. > Following that (IMHO valid) logic makes it impossible to _ever_ add new > lookup types to django without breaking backwards compatibility since field > lookup types and field names share the same namespace. > > Interestingly there has been one instance [5] where a lookup type was added > after the 1.0 release (as far as I could gather from SVN). Why no backward > comp. concerns were voiced in that case is not clear from the ticket. > > Also there is currently no validation preventing field names from clashing > with the already existing lookup types (date, year, month, day, etc. are > IMHO "easy targets"). Whether that would be a desirable feature to have is > also debatable since it would "artificially" limit a developers naming > choices. > That using conflicting field names usually causes no problems but blows up > with a rather confusing error message (e.g. "TypeError: Related Field has > invalid lookup: [...]") when querying for that field through a relation > without an explicit lookup isn't helpful either. > > To solve this situation I think there are two possibilities: > > 1. Make the current implementation "smarter": Don't automatically assume > that the last filter part is a lookup type but instead check first if there > is a field of that name. > 2. Separate the field name and lookup namespaces: > Either change the separator for lookup types (e.g. to 3 underscores) or > introduce a completely different way of specifying lookups (e.g. > Thing.objects.filter(some_field__other_field=lookups.Contains("blah"))) > > Option one clearly is far less invasive (and possible to implement short > term) but has the potential of user / developer confusion and maybe some > hard-to-get-right edge cases. > Option two is a big hammer and possibly (probably?) not something the core > devs are willing to change even in the long term? > > So what do people think? > > Bye Ulrich > > [1]http://code.djangoproject.com/ticket/8424 > [2]http://code.djangoproject.com/ticket/9596 > [3]http://code.djangoproject.com/ticket/10911 > [4]http://code.djangoproject.com/ticket/12489 > [5]http://code.djangoproject.com/changeset/9818 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. 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.
