Re: Add an optional parameter to values() that returns a nested dictionary for foreign keys

[Josh Smeaton]

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  > 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-develop...@googlegroups.com . 
> > To post to this group, send email to django-d...@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/80d0aa4c-bdac-433b-96b5-cbde00bec257%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add an optional parameter to values() that returns a nested dictionary for foreign keys

[Constantine Covtushenko]

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’)).
>
> --
> 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 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.
>

-- 
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/CAK52boUjjLwDkxnF5mU_SCCypzPL5Yy5Byto8nEk3O3xoVUGDw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add an optional parameter to values() that returns a nested dictionary for foreign keys

[Loïc Bistuer]

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 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.

I've found a better way of getting the correct sequence name on postgres

[Hanne Moa]

We needed to switch a table from using one sequence to another as the
first stage in merging two tables, and discovered that django can't
pick up the new sequence-name. Actually, it's the postgres-function
that the backend uses that is at fault.

Fortunately I found a way to introspect for the sequence name that
works in many more cases than the current use of
pg_get_serial_sequence: looking up the default value of a column in
"information_schema.columns", column "column_default". See ticket
#27090, https://code.djangoproject.com/ticket/27090 for some code.

While I'm scratching my immediate itch by updating the forked
postgres-backend we have to use anyway, switching away from
pg_get_serial_sequence would make life much easier and with fewer
surprises for everyone.

I will make a minimalistic, forked backend as a package (as soon as I
understand the style.SQL-stuff) but I do think that not using
pg_get_serial_sequence would be a general improvement for Django 1.11.

-- 
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/CACQ%3DrreHWKjPteti2uhbvCQUZgDJGF5VjdMfcQppvaK2RiY%3DcQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.