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
may be useful https://github.com/aklim007/DjangoNestedValues
--
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-develo
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
Agree with Loïc on 100%.
And also it opens more options in the future.
Regards,
On Fri, Aug 19, 2016 at 9:58 PM, 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’)).
>
> --
> L
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 wrote:
>
> We now have support for expressions in values()/values_list() -- thanks Ian!
> With t
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 automati
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 suppo
On Wednesday 25 November 2015 20:34:11 Marc Tamlyn wrote:
> I can see a use for this, but the API is unsure. Given that from a
> performance point of view it should be possible to do this as a transform
> after a values query (in most cases using a similar lazy sequence-like
> object will maintain
I can see a use for this, but the API is unsure. Given that from a
performance point of view it should be possible to do this as a transform
after a values query (in most cases using a similar lazy sequence-like
object will maintain the performance you need), can I propose implementing
it as an ext
I think I wasn't clear from the beginning, the idea of "nested" is to nest
all possible levels, not just a single level. I like the idea of "N", given
that you can have more control, but having something like N("person",
"person__hometown", "person__hometown__country") which will be different
t
Marten's suggestion is quite interesting for providing a way to tell which
data you want nested and which data you don't. Plus, this form might be
interesting to solve another problem : how would Django know if we want :
{"id": 1
"first_name": "first name",
"last_name": "last name",
"hometown
I like the idea but what about multiple nesting, multiple foreign keys?
We end up with something like N('author__book')? a bit confusing no?
On Wednesday, November 25, 2015 at 6:53:25 PM UTC+2, Marten Kenbeek wrote:
>
> I think it'd be more consistent with other parts of the ORM to use
> **kwarg
I think it'd be more consistent with other parts of the ORM to use **kwargs
to specify aliases. For nested data you can use an object, say N, similar
to Q and F objects:
Articles.objects.filter(id=1).values('body', N('author'), my_custom_title=
'title')
I'm no ORM expert, but could something li
Well, switch the field name aliasing to a dictionary without hijacking
**kwargs ?
I prefer the following:
Articles.objects.get(id=1).values(’title’, ’author’, ‘body',
alias={"title": "my_custom_title"}, nested=True)
On Wednesday, November 25, 2015 at 5:43:51 PM UTC+2, Tim Graham wrote:
>
> Th
A useful overall target for the next Django version would be to try and get all
these feature up so that high-speed REST API development becomes easier.
(really need to be able to push thousands of requests per second)
I’d like to directly go from Query to Response:
response = JsonResponse(A
There's an accepted ticket for adding aliasing to values():
https://code.djangoproject.com/ticket/16735
The current patch there hijacks values() **kwargs for the mapping of
renamed fields which would prevent adding other kwargs like "nested"
without disallowing those values as aliases. I guess
100%, that would be great also. I thought of just posting the basic
requirement that might be useful to most.
On Wednesday, November 25, 2015 at 5:20:37 PM UTC+2, Bobby Mozumder wrote:
>
> I could also use a couple of enhancement to this:
>
> 1) Allow renaming of keys, instead of using the databa
I could also use a couple of enhancement to this:
1) Allow renaming of keys, instead of using the database column names.
2) Allow callbacks functions (or lambdas) to convert output values to another
format if needed.
With this, I could send the queries results right to JSON outputs.
-bobby
>
Currently, after calling values() and the query executes, the output is a
single level dictionary, including foreign keys. I propose adding an extra
parameter for values, or at least values_list, where if it's set to true, a
nested dictionary will be returned when there's a foreign key.
Example
19 matches
Mail list logo
