#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 [email protected].
To post to this group, send email to [email protected].
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.
