I think the consensus here is to not add the extra commit, so I've
closed the ticket as wontfix.
(https://code.djangoproject.com/ticket/16735#comment:26)
Ian
On 20/08/16 15:24, Josh Smeaton wrote:
Just as an additional data point - most expressions that accept
strings internally convert them to F(), so it's not entirely
inconsistent with other behaviour. I don't really have a preference
here though, so happy to go with what the majority prefer.
On Saturday, 20 August 2016 04:59:10 UTC+10, Loïc Bistuer wrote:
I prefer enforcing .values(alias=F(’something’)), to me
.values(alias=‘something’) reads as the equivalent of
.values(alias=Value(‘something’)).
--
Loïc
> On Aug 20, 2016, at 1:04 AM, Tim Graham <timog...@gmail.com
<javascript:>> wrote:
>
> We now have support for expressions in values()/values_list() --
thanks Ian! With the new commit [0], aliases can be created like
this: .values(alias=F('field'))
>
> Ian has offered an additional commit in the pull request [1] to
allow .values(alias='field') (without the F() expression) to
automatically wrap the string in an F() expression to create an
alias. I'm not sure whether or not to accept that patch as I think
I prefer the look of the explicit F() rather than magically
treating strings as F() expressions. What do you think?
>
> [0]
https://github.com/django/django/commit/39f35d4b9de223b72c67bb1d12e65669b4e1355b
<https://github.com/django/django/commit/39f35d4b9de223b72c67bb1d12e65669b4e1355b>
> [1] https://github.com/django/django/pull/7088
<https://github.com/django/django/pull/7088>
>
> On Wednesday, November 25, 2015 at 7:24:22 PM UTC-5, Josh
Smeaton wrote:
> I would really like two things for values to support.
>
> 1. Aliases .values(alias='field');
> 2. Expressions .values(alias=F('field'))
>
> I think these two features are absolute must haves, and the
syntaxes above are already standard in other parts of the ORM.
>
> If someone can come up with a way to support nested relations
while supporting the above syntax, then I'd be OK with that. But
at the moment, I'm firmly in the "this is the responsibility of a
serialiser" camp. I'm not convinced Django needs to support nested
objects at all. Is this something you could implement with your
own queryset method on a manager? Is this maybe something we could
look at creating a new queryset method called .values_dict() ?
>
> If it weren't for backwards compatibility, I'd suggest that
referencing the related object would automatically nest that
object. That would differentiate between the id and the field
values('related_id', 'related') -> '{"related_id": 1, "related":
{"id": 1, ..}}'.
>
> If there's (rough) consensus on having nested objects, then we
could allow something like: .values(..., ..., nested=('related',
'related__otherrelated')). If the value of nested is an iterable
then assume we're nesting, otherwise nested is an alias for the
field. I don't particularly like overloaded kwargs, but we're just
guarding against someone wanting to alias as "nested" which we
could call out in docs anyway.
>
> The more I think about this the more I think nesting and aliases
within a nest should probably be done in a different queryset
method. Or just handled by a serialiser. If you want more requests
per second, then add some more backends.
>
> --
> You received this message because you are subscribed to the
Google Groups "Django developers (Contributions to Django itself)"
group.
> To unsubscribe from this group and stop receiving emails from
it, send an email to django-develop...@googlegroups.com
<javascript:>.
> To post to this group, send email to
django-d...@googlegroups.com <javascript:>.
> Visit this group at
https://groups.google.com/group/django-developers
<https://groups.google.com/group/django-developers>.
> To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/00d4305c-175e-415c-b446-a53c7d15c00d%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/00d4305c-175e-415c-b446-a53c7d15c00d%40googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout
<https://groups.google.com/d/optout>.
--
You received this message because you are subscribed to the Google
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to django-developers+unsubscr...@googlegroups.com
<mailto:django-developers+unsubscr...@googlegroups.com>.
To post to this group, send email to
django-developers@googlegroups.com
<mailto:django-developers@googlegroups.com>.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/80d0aa4c-bdac-433b-96b5-cbde00bec257%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/80d0aa4c-bdac-433b-96b5-cbde00bec257%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Django
developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/48dae707-c525-121b-0434-b78bde4f407f%40feete.org.
For more options, visit https://groups.google.com/d/optout.
