#23940: Disallow/warn on fields named exact
-------------------------------------+-------------------------------------
Reporter: zhiyajun11 | Owner: nicwest
Type: New feature | Status: assigned
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Ready for
| checkin
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by MarkusH):
I was thinking about a more general solution that takes all registered
lookups and transforms into account.
{{{
MarkusH | wouldn't it make more sense to raise errors if fields,
transforms and/or lookups clash?
collinanderson | MarkusH: no idea. i haven't messed around with custom
lookups
MarkusH | jarshwah_: if you are around ---^
collinanderson | MarkusH: right, i was thinking that, but it's only an
issue for primary_key fields, right?
collinanderson | MarkusH: or any field referenced by a foreignkey
MarkusH | I think it's a general problem
MarkusH | any field you can possibly reference via relations
MarkusH | if you have a standalone model, no FK pointing to or
from, you should be safe
MarkusH | collinanderson: so, what do I do with the issue now? Do I
set its triage state back to accepted after I dumped my thoughts there?
collinanderson | MarkusH: hah. i'm totally not a triager-expert.
collinanderson | MarkusH: but let's say you have book with fk->author
collinanderson | MarkusH: ohh, i get it. yeah
MarkusH | ok
collinanderson | MarkusH: ohh, see, you could do either
book_author_id__gte=2
collinanderson | MarkusH: or book__author__id__gte=2
collinanderson | MarkusH: both of those would work with a field on author
named "gte"
collinanderson | right?
MarkusH | yes
collinanderson | and django doesn't really do that internally at all, but
id _does_ do __exact a bunch
collinanderson | right? (at least this ^^ is my assumption)
MarkusH | but what about book__author__foo='bar' (where foo can be
a field, transform or lookup) do?
collinanderson | right, and in that case it should be a field, not a
transform or lookup
MarkusH | afaik, if no lookup is given, exact is assumed
collinanderson | seems to me you if you wanted a transform/lookup in that
case you could just do book__author__pk__foo='bar'
collinanderson | or book__author_id__foo='bar'
MarkusH | ahh, right
MarkusH | thanks
collinanderson | and maybe it's possible to change django so it allows for
a field named "exact" in the same way
MarkusH | hang on
collinanderson | (i'm saying this all in theory, i haven't actually tried
any of this :)
MarkusH | the test case attached to the PR has a model with a field
"exact"
collinanderson | and i assume the bad news is it uses the lookup/transform
instead of the field?
MarkusH | ok. The PR is about preventing certain problems by not
allowing them to happen
MarkusH | it specializes the exact lookup
MarkusH | it isn't about a way to find another way to access a
field
MarkusH | so, in practice, every lookup and transform should
prevent a field of that name
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/23940#comment:13>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/068.e30e068171c84d4a9d4071b2aaacaf82%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
