Re: Featurereuqest: Helpfull tracebacks

[Aymeric Augustin]

As soon as Django drops support for Python 2 :)

-- 
Aymeric.

Le 22 août 2013 à 06:43, Ben Finney  a écrit :

> 
> This could be done by having Django's database interface catch the
> error, and chain a new exception from that one:

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Custom prefetches (#17001)

[Marc Tamlyn]

The other restriction imposed by your suggested api is that the Count or
Model list will presumably only know the standard queryset api - with a
queryset= parameter any custom qs methods will work.

This is perhaps more necessary in the annotate case as it is naturally a
restricted api - select related makes no sense.

Marc
On 23 Aug 2013 18:44, "Andrew Ingram"  wrote:

> Yeah, that was Marc's main issue with the idea too. Based on that
> distinction it makes sense to keep the two as separate concepts, but as far
> as API design is concerned it makes sense to try and make them feel similar.
>
>
> On 23 August 2013 18:25, Anssi Kääriäinen  wrote:
>
>> On Friday, August 23, 2013 6:25:42 PM UTC+3, Andrew Ingram wrote:
>>>
>>> I'd love to see this solved. I'm not sold on the API, but then again
>>> I've yet to see a single suggested API for this problem that I actually
>>> like.
>>>
>>> I showed you this a little while ago, you had some reservations with my
>>> idea, but I figured I might as well add it to the conversation anyway:
>>> https://gist.github.**com/AndrewIngram/5636041
>>>
>>> Essentially, I'm wondering if extending the prefetch_related concept is
>>> the right approach, and whether it's instead worth exploring the more
>>> general idea of "attaching stuff to models at the ORM level". There're a
>>> lot of useful concepts from other ORMs related to attaching prebuilt data
>>> structures like arrays, dicts, calculated values, filtered annotations, etc
>>> to models. The problems all seem somewhat related, and I'm worried about
>>> the possibility of solving them all in completely different ways.
>>>
>>
>> I don't like the idea of mixing annotate() and prefetch_related().
>> Annotations work inside the query, prefetch_related runs additional queries.
>>
>> That being said I do like the idea of
>> .annotate(active_authors=Count('authors').filter(active=True)). There is an
>> old ticket about this sort of annotation, see
>> https://code.djangoproject.com/ticket/11305.
>>
>>  - Anssi
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" 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 http://groups.google.com/group/django-developers.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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 http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Custom prefetches (#17001)

[Andrew Ingram]

Yeah, that was Marc's main issue with the idea too. Based on that
distinction it makes sense to keep the two as separate concepts, but as far
as API design is concerned it makes sense to try and make them feel similar.


On 23 August 2013 18:25, Anssi Kääriäinen  wrote:

> On Friday, August 23, 2013 6:25:42 PM UTC+3, Andrew Ingram wrote:
>>
>> I'd love to see this solved. I'm not sold on the API, but then again I've
>> yet to see a single suggested API for this problem that I actually like.
>>
>> I showed you this a little while ago, you had some reservations with my
>> idea, but I figured I might as well add it to the conversation anyway:
>> https://gist.github.**com/AndrewIngram/5636041
>>
>> Essentially, I'm wondering if extending the prefetch_related concept is
>> the right approach, and whether it's instead worth exploring the more
>> general idea of "attaching stuff to models at the ORM level". There're a
>> lot of useful concepts from other ORMs related to attaching prebuilt data
>> structures like arrays, dicts, calculated values, filtered annotations, etc
>> to models. The problems all seem somewhat related, and I'm worried about
>> the possibility of solving them all in completely different ways.
>>
>
> I don't like the idea of mixing annotate() and prefetch_related().
> Annotations work inside the query, prefetch_related runs additional queries.
>
> That being said I do like the idea of
> .annotate(active_authors=Count('authors').filter(active=True)). There is an
> old ticket about this sort of annotation, see
> https://code.djangoproject.com/ticket/11305.
>
>  - Anssi
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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 http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Custom prefetches (#17001)

[Anssi Kääriäinen]

On Friday, August 23, 2013 6:25:42 PM UTC+3, Andrew Ingram wrote:
>
> I'd love to see this solved. I'm not sold on the API, but then again I've 
> yet to see a single suggested API for this problem that I actually like.
>
> I showed you this a little while ago, you had some reservations with my 
> idea, but I figured I might as well add it to the conversation anyway: 
> https://gist.github.com/AndrewIngram/5636041
>
> Essentially, I'm wondering if extending the prefetch_related concept is 
> the right approach, and whether it's instead worth exploring the more 
> general idea of "attaching stuff to models at the ORM level". There're a 
> lot of useful concepts from other ORMs related to attaching prebuilt data 
> structures like arrays, dicts, calculated values, filtered annotations, etc 
> to models. The problems all seem somewhat related, and I'm worried about 
> the possibility of solving them all in completely different ways.
>

I don't like the idea of mixing annotate() and prefetch_related(). 
Annotations work inside the query, prefetch_related runs additional queries.

That being said I do like the idea of 
.annotate(active_authors=Count('authors').filter(active=True)). There is an 
old ticket about this sort of annotation, see 
https://code.djangoproject.com/ticket/11305.

 - Anssi

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Custom prefetches (#17001)

[Andrew Ingram]

I'd love to see this solved. I'm not sold on the API, but then again I've
yet to see a single suggested API for this problem that I actually like.

I showed you this a little while ago, you had some reservations with my
idea, but I figured I might as well add it to the conversation anyway:
https://gist.github.com/AndrewIngram/5636041

Essentially, I'm wondering if extending the prefetch_related concept is the
right approach, and whether it's instead worth exploring the more general
idea of "attaching stuff to models at the ORM level". There're a lot of
useful concepts from other ORMs related to attaching prebuilt data
structures like arrays, dicts, calculated values, filtered annotations, etc
to models. The problems all seem somewhat related, and I'm worried about
the possibility of solving them all in completely different ways.

Regards,
Andy



On 23 August 2013 16:03, Marc Tamlyn  wrote:

> Ticket #17001 concerns the ability to customise the querysets used when
> using `prefetch_related()`. This has a working implementation with a less
> than ideal API - see the patches on the ticket.
>
> As the API design seems to be the main issue here, Anssi and I bounced
> some ideas around on IRC, and I thought it best to propose our best
> approach here to gather opinions on whether the API is palatable.
>
> Firstly note that the existing API would continue to work as it does now:
> Publisher.objects.prefetch_related('authors', 'authors__books')
> You can then access publisher.authors.all() as before, each of which will
> allow you to access author.books.all()
>
> If you wanted to prefetch the authors ordered by their age rather than
> whatever the default is, you can do:
> Publisher.objects.prefetch_related('authors', to_attr='authors_by_age',
> queryset=Author.objects.order_by('age'))
> The authors are now available as publisher.authors_by_age - this is a list
> (not a qs) of the relevant Author objects.
>
> Only one custom field can be prefetched at once in this way. So if you
> wanted to get the books prefetched as well, you would need to do:
> Publisher.objects.prefetch_related('authors', to_attr='authors_by_age',
> queryset=Author.objects.order_by('age').prefetch_related('books'))
>
> An alternative API that may work for this case is:
> Publisher.objects.prefetch_related('authors', to_attr='authors_by_age',
> queryset=Author.objects.order_by('age')).prefetch_related('authors_by_age__books')
> i.e. the custom prefetch can be referenced in future chained prefetch
> calls.
>
> This API can be used to customise the second level only:
> Publisher.objects.prefetch_related('authors').prefetch_related('authors__books',
> to_attr='unpublished_books', queryset=Book.objects.filter(published=False))
>
> If you want to customise both levels though, you must use the first
> approach:
> author_qs = Author.objects.order_by('age').prefetch_related('books',
> to_attr='unpublished_books', queryset=Book.objects.filter(published=False))
> Publisher.objects.prefetch_related('authors', to_attr='authors_by_age',
> queryset=author_qs)
>
>
> Opinions are welcome!
>
> Marc
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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 http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Custom prefetches (#17001)

[Marc Tamlyn]

Ticket #17001 concerns the ability to customise the querysets used when
using `prefetch_related()`. This has a working implementation with a less
than ideal API - see the patches on the ticket.

As the API design seems to be the main issue here, Anssi and I bounced some
ideas around on IRC, and I thought it best to propose our best approach
here to gather opinions on whether the API is palatable.

Firstly note that the existing API would continue to work as it does now:
Publisher.objects.prefetch_related('authors', 'authors__books')
You can then access publisher.authors.all() as before, each of which will
allow you to access author.books.all()

If you wanted to prefetch the authors ordered by their age rather than
whatever the default is, you can do:
Publisher.objects.prefetch_related('authors', to_attr='authors_by_age',
queryset=Author.objects.order_by('age'))
The authors are now available as publisher.authors_by_age - this is a list
(not a qs) of the relevant Author objects.

Only one custom field can be prefetched at once in this way. So if you
wanted to get the books prefetched as well, you would need to do:
Publisher.objects.prefetch_related('authors', to_attr='authors_by_age',
queryset=Author.objects.order_by('age').prefetch_related('books'))

An alternative API that may work for this case is:
Publisher.objects.prefetch_related('authors', to_attr='authors_by_age',
queryset=Author.objects.order_by('age')).prefetch_related('authors_by_age__books')
i.e. the custom prefetch can be referenced in future chained prefetch calls.

This API can be used to customise the second level only:
Publisher.objects.prefetch_related('authors').prefetch_related('authors__books',
to_attr='unpublished_books', queryset=Book.objects.filter(published=False))

If you want to customise both levels though, you must use the first
approach:
author_qs = Author.objects.order_by('age').prefetch_related('books',
to_attr='unpublished_books', queryset=Book.objects.filter(published=False))
Publisher.objects.prefetch_related('authors', to_attr='authors_by_age',
queryset=author_qs)


Opinions are welcome!

Marc

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Featurereuqest: Helpfull tracebacks

[Florian Apolloner]

On Friday, August 23, 2013 4:52:16 AM UTC+2, Ben Finney wrote:
>
> I didn't see a traceback. The OP gave only the error message. How do you 
> know they are getting the model name? 
>

If he had shown his full traceback you'd see how django came to execute 
this query; when it reaches your code you'll see which model you tried to 
insert/query there…

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: password reset email template tags

[Jorge Cardoso Leitão]

Hi jupiter

This mailing list is for the development of Django itself.
Please refer to django-users mailing list for questions about the usage of 
Django.

Cheers,
Jorge

On Aug 23, 2013, at 1:33 PM, nobody wrote:

> Hi,
> 
> I have customized template tags such as {{ org_name }} and {{ account_email 
> }} which work fine for most of email template files and html files, but the 
> tags {{ org_name }} and {{ account_email }} could not work with password 
> reset email template. The django/contrib/auth/forms.py defined several 
> arguments for password reset, such as domain, site_name, user and email. I 
> can override the domain by "domain_override", but I cannot add the tags to 
> it. How can I make the {{ org_name }} and {{ account_email }} tags working 
> with my password reset email template file (password_reset_email.html)?
> 
> Thank you.
> 
> jupiter
> 
>  
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" 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 http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

password reset email template tags

[nobody]

Hi,

I have customized template tags such as {{ org_name }} and {{ account_email 
}} which work fine for most of email template files and html files, but the 
tags {{ org_name }} and {{ account_email }} could not work with password 
reset email template. The django/contrib/auth/forms.py defined several 
arguments for password reset, such as domain, site_name, user and email. I 
can override the domain by "domain_override", but I cannot add the tags to 
it. How can I make the {{ org_name }} and {{ account_email }} tags working 
with my password reset email template file (password_reset_email.html)?

Thank you.

jupiter

 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: More input on #20945

[charettes]

Don't know if my last message made it to the mailing list, it looks like 
google-group might have eaten it. If it's not the case sorry for the noise.

Concerning (2) I do agree with Carl it's not required to default to a 
specific template fragment cache alias. For the uncommon cases you want to 
cache template fragments using another cache backend a simple template 
context processor should do:

# context_processors.py
def template_cache(context):
context['template_cache']

# template.html
{% cache using=template_cache %}...{% endcache %}

Le mercredi 21 août 2013 08:05:58 UTC-4, Curtis Maloney a écrit :
>
> Was just after some more eyes and opinions on 
> https://code.djangoproject.com/ticket/20945
>
> Current PR is at: https://github.com/django/django/pull/1490
>
> This patch does two things:
>
> 1) it allows specifying on a {% cache %} tag which cache to use
>
> {% cache . using="cachename" %}
>
> 2) it makes the cache tag try to use a cache called "template_fragments" 
> if it exists, and otherwise use "default"
>
> This is following on from the pattern established in staticfiles, where 
> the CachedFilesMixin will try to use a cache called "staticfiles" if 
> available.
>
> So far everyone involved agrees with (1)
>
> However, the reception of (2) has so far been... luke warm.
>
> So I was hoping for more eyes/input on this...
>
> --
> Curtis
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.