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 <timogra...@gmail.com> 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
> [1] 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-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/00d4305c-175e-415c-b446-a53c7d15c00d%40googlegroups.com.
> 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/C7D98DF5-5F48-4E89-849F-D5E28A93D1DE%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
