Re: Adding signals to bulk update/create operations

[Anssi Kääriäinen]

On Friday, March 31, 2017 at 10:50:54 AM UTC+3, Todor Velichkov wrote:
>
> @Anssi, thank you for your response.
> I really haven't think about threat safety, but maybe its because in our 
> specific usage it's close to impossible to happen.
>
> What do you think about this:
> 1) Put everything into a transaction
> 2) Before update, count the queryset.
> 3) Fire the pre_update with the queryset, and the count.
> 4) Do the actual update -> get the updated rows
> 5) Assert the updated rows is equal to the queryset.count().
> 6) Revert the transaction if there is a difference.
>
> No pk fetching, this is left to the be implemented by the listener if he 
> needs it.
>

I'm afraid this won't work well enough. It does work for many use cases, 
but in cases where concurrency is an issue, you'd get some loud failures, 
and worse, you could get cases where things work silently wrong (one item 
removed, one added concurrently). These cases would be near-impossible to 
debug.

The reason why we don't have update signals is that it's hard to find a 
solution that allows users to run actions when an instance is updated, 
works correctly in concurrent cases and with large amount of objects and 
doesn't turn bulk update in to a loop of save() calls.

Maybe the best approach is to look for a solution where users can customise 
update behaviour for remote models if they so wish. Then you could write 
your own update signals solution, one that doesn't need to care about all 
of the above constraints.

 - Anssi

-- 
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/fd81d210-a2d6-4e7a-9eb0-d3f8f078a032%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 1.8 - django 1.7 differences to read DecimalField

[Tim Graham]

I'd suggest to use git bisect to find the Django commit where the behavior 
changed:
https://docs.djangoproject.com/en/dev/internals/contributing/triaging-tickets/#bisecting-a-regression

On Wednesday, April 5, 2017 at 5:57:03 PM UTC-4, Maximiliano Robaina wrote:
>
> Hi,
>
>
> I'm the maintener of django-firebird database backend.
>
> I've an strange behavior (a different result) when reading a value from a 
> DecimalField between Django 1.7 and Django 1.8 and I'm trying to figured 
> out where is my mistake.
>
> I've a django project which I update from 1.7 to 1.8.
> In this project I've a model with a DecimalField.  (by example, price 
> = DecimalField(max_digits=18, decimal_places=2)
>
> Then, in django 1.7
>
> >> obj = ModelWithDecimalField.objects.first()
> >> obj.price
> >>  Decimal("1990.00")
>
> In django 1.8
>
> >> obj = ModelWithDecimalField.objects.first()
> >> obj.price
> >>  Decimal("1990")
>
>
> So, I don't know where look to found this change. What change between 1.7 
> and 1.8
> Maybe I forget to implement something in django-firebird 1.8
>
>
> Thanks in advance
> Maxi
>
>
>
>
>
>
>

-- 
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/538ec818-854f-475b-be7c-5078f240073d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django 1.8 - django 1.7 differences to read DecimalField

[Maximiliano Robaina]

Hi,


I'm the maintener of django-firebird database backend.

I've an strange behavior (a different result) when reading a value from a 
DecimalField between Django 1.7 and Django 1.8 and I'm trying to figured 
out where is my mistake.

I've a django project which I update from 1.7 to 1.8.
In this project I've a model with a DecimalField.  (by example, price 
= DecimalField(max_digits=18, decimal_places=2)

Then, in django 1.7

>> obj = ModelWithDecimalField.objects.first()
>> obj.price
>>  Decimal("1990.00")

In django 1.8

>> obj = ModelWithDecimalField.objects.first()
>> obj.price
>>  Decimal("1990")


So, I don't know where look to found this change. What change between 1.7 
and 1.8
Maybe I forget to implement something in django-firebird 1.8


Thanks in advance
Maxi






-- 
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/33cca19c-edc1-4ff1-a8d8-10f0db5a87c9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [feature request] including HttpResponse(status=204) as an HttpResponse subclasses

[Tim Graham]

Hi, this was already wontfixed here:
https://code.djangoproject.com/ticket/3362

with the rationale, "We've decided in the past not to add a new class for 
every single response code. You can already pass the status code in when 
creating the HttpResponse class, so that can be used in this case."

(found with this google search: httpresponse 204 
site:code.djangoproject.com)

On Wednesday, April 5, 2017 at 11:25:44 AM UTC-4, Philip Lee wrote:
>
> Every Django view function MUST return an HttpResponse object, sometimes we 
> just want to send data to the server and  don't want to send data back to the 
> client , this probably lead Python users want to return None instead, however 
> , this is not allowed in Django view function, I found  
> HttpResponse(status=204) 
>  may come for 
> rescue in this case,  thus it would be better to include 
> HttpResponse(status=204) as an HttpResponse subclasses for convenience so 
> that could save Django users from asking those returning-null-response 
> questions:http://stackoverflow.com/questions/17557618/post-without-response-in-django-javascript-interactionhttp://stackoverflow.com/questions/2131203/django-no-redirectionshttp://stackoverflow.com/questions/4123155/how-do-i-send-empty-response-in-django-without-templates
>
> BTW, someone already implemented this feature  here, better to adopt it in 
> Django http://django-extras.readthedocs.io/en/latest/ref/http-response.html
>
>

-- 
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/1ad91569-9373-45ec-9307-09e20caf9e6a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: proposal: add special subclass of ForeignKey for storing ContentTypes

[Adam Johnson]

Sergey, I like the idea. It at least serves as a demonstration of what can
be done with custom fields. The PoC shows it's not too much code either.
Would you be looking to replace the existing FK's to ContentType too, e.g.
in Admin and Auth?

On 5 April 2017 at 06:24, Asif Saifuddin  wrote:

> Hi Sergey,
>
> I was also wondering why GenericForeignKey don't have direct subclass of
> ForeignKey while writing a dep about field API improvement. Though I am not
> 100% sure your implementation.
>
> Thanks for bringing it up.
>
>
>
> On Wednesday, April 5, 2017 at 2:46:31 AM UTC+6, Sergey Fedoseev wrote:
>>
>> Hi all,
>>
>> Some time ago I created 'new feature` ticket
>>  and Tim Graham asked me to
>> write here to get some feedback on the idea. So here it is.
>>
>> ContentType model is quite specific, so we could add the subclass of
>> ForeignKey with some specific features.
>>
>>
>> For example, we have a model:
>>
>>
>> class ModelWithContentType(models.Model):
>> ct = ContentTypeField(on_delete=models.CASCADE)
>>
>>
>> In comparison with ForeignKey ContentTypeField will have these features:
>>
>>1. ModelWithContentType.objects.first().ct will use content types
>>cache
>>
>>
>>1. ContentTypeField will support lookups on the model classes (on
>>model instances too?):
>>
>> ModelWithContentType.objects.filter(ct=FooModel) vs.
>>
>> ModelWithContentType.objects.filter(ct=ContentType.objects.g
>> et_for_model(FooModel))
>>
>>
>> ModelWithContentType.objects.filter(ct__in=[FooModel, BarModel]) vs.
>> ModelWithContentType.objects.filter(ct__in=[ContentType.objects.get_for_model(model)
>> in [FooModel, BarModel]])
>>
>>1. Creation using a model class as a value (not sure if it's useful
>>actually):
>>
>> ModelWithContentType.objects.create(ct=FooModel)
>>
>>
>> Here's ​rough implementation
>> .
>>
> --
> 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/0764f9bc-be05-47ac-8201-
> b419a93d3061%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Adam

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

[feature request] including HttpResponse(status=204) as an HttpResponse subclasses

[Philip Lee]

Every Django view function MUST return an HttpResponse object, sometimes we 
just want to send data to the server and  don't want to send data back to the 
client , this probably lead Python users want to return None instead, however , 
this is not allowed in Django view function, I found  HttpResponse(status=204) 
 may come for 
rescue in this case,  thus it would be better to include 
HttpResponse(status=204) as an HttpResponse subclasses for convenience so that 
could save Django users from asking those returning-null-response questions:
http://stackoverflow.com/questions/17557618/post-without-response-in-django-javascript-interaction
http://stackoverflow.com/questions/2131203/django-no-redirections
http://stackoverflow.com/questions/4123155/how-do-i-send-empty-response-in-django-without-templates

BTW, someone already implemented this feature  here, better to adopt it in 
Django 
http://django-extras.readthedocs.io/en/latest/ref/http-response.html

-- 
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/76aefb01-5b00-4df8-9210-4f064ca74aeb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django versioning and breaking changes policy

[James Pic]

I think people are always going to run into such kind of issues until they
decide to add django-master to their test matrix​, so that each dependency
and project should always have the chance to be ready for the next version
of Django "0day". But perhaps I'm missing something.

Best
James

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

Re: Django 1.11 released

[Florian Apolloner]

Not on purpose no -- if it doesn't work with 4.1 that is a bug

On Wednesday, April 5, 2017 at 11:07:13 AM UTC+2, jorr...@gmail.com wrote:
>
> Is the required version of Pillow pinned at 4.0.0? I upgraded to Django 
> 1.11 and from Pillow 4.0.0 to 4.1.0 but now Django doesn't start because it 
> says I can't use ImageField without installing Pillow. Downgrading to 
> Pillow 4.0.0 fixes this.
>
>
> On Tuesday, April 4, 2017 at 6:09:40 PM UTC+2, Tim Graham wrote:
>>
>> Django 1.11, the next long-term support release, is now available:
>>
>> https://www.djangoproject.com/weblog/2017/apr/04/django-111-released/
>>
>> With the release of Django 1.11, Django 1.10 has reached the end of 
>> mainstream support. The final minor bugfix release (1.10.7) was issued 
>> today. Django 1.10 will receive security and data loss fixes for another 
>> eight months until December 2017.
>>
>> Django 1.9 has reached the end of extended support. The final security 
>> release (1.9.13) was issued today. All Django 1.9 users are encouraged to 
>> upgrade to Django 1.10 or later.
>>
>> See the downloads page [1] for a table of supported versions and the 
>> future release schedule.
>>
>> [1] https://www.djangoproject.com/download/#supported-versions
>>
>

-- 
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/5ebf0769-452d-44b1-9241-acb3da2f31db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 1.11 released

[jorrit787]

Is the required version of Pillow pinned at 4.0.0? I upgraded to Django 
1.11 and from Pillow 4.0.0 to 4.1.0 but now Django doesn't start because it 
says I can't use ImageField without installing Pillow. Downgrading to 
Pillow 4.0.0 fixes this.


On Tuesday, April 4, 2017 at 6:09:40 PM UTC+2, Tim Graham wrote:
>
> Django 1.11, the next long-term support release, is now available:
>
> https://www.djangoproject.com/weblog/2017/apr/04/django-111-released/
>
> With the release of Django 1.11, Django 1.10 has reached the end of 
> mainstream support. The final minor bugfix release (1.10.7) was issued 
> today. Django 1.10 will receive security and data loss fixes for another 
> eight months until December 2017.
>
> Django 1.9 has reached the end of extended support. The final security 
> release (1.9.13) was issued today. All Django 1.9 users are encouraged to 
> upgrade to Django 1.10 or later.
>
> See the downloads page [1] for a table of supported versions and the 
> future release schedule.
>
> [1] https://www.djangoproject.com/download/#supported-versions
>

-- 
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/20403ada-0688-4192-9aef-8904f10d43d8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Custom Site model support for django.contrib.sites

[Massimo Scamarcia]

Hello, I would like to use a custom Site model, in a similar way as 
implemented for django.contrib.auth.users.

As discussed here https://code.djangoproject.com/ticket/27784 there is also 
another ticket and patch for that, but with a different approach.

My pull request: https://github.com/django/django/pull/7961

Thanks,
Massimo

-- 
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/78c3f727-6ddd-4ad5-b6fc-e71b76743ea6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vietnamese Django full text search in postgres.

[Marc Tamlyn]

Hi Cử Nhữ Văn,

This mailing list is for development of Django itself, rather than support
queries. You may get a better answer on the main mailing list or on #django
on IRC.

You may also find some help about different languages in the docs:
https://docs.djangoproject.com/en/1.10/ref/contrib/postgres/search/#postgresql-fts-search-configuration

On 2 April 2017 at 16:23, Cử Nhữ Văn  wrote:

> Hi Django developers!
> I'm newbie in django. I have a problem with Vietnamses full text search in
> postgres DB. Please help me!
> I have a website supported English and Vietnamese. When I search with
> English, everything ok. When I search with Vietnamese, I got problem:
> When i inputed "gia" it only return result of "gia". But I need result
> include "gia, giá, giả, già".
> I got nothing when i search on google. Does Django support this? and how
> can i implement?
> Thank you so much!
>
> --
> 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/4b69805b-376b-4c55-ae25-
> ed05ecb83547%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/CAMwjO1Gi7%3DkRdC6JEi%2BxSqOFOJX%2B1_0E-BjGLhKjaVy_x0g9CA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Provide 'V' as alias for 'Value'?

[Marc Tamlyn]

Given that you can always do import Value as V, I'm not sure providing an
alias is necessary.

On 3 April 2017 at 12:15, Josh Smeaton  wrote:

> I think I proposed V as an alias back when I was writing the patch, but
> the rough consensus at the time was that one letter class names are a bit
> of an anti pattern (Q, F) that we shouldn't persist with. Aliasing V in the
> examples was my way of sneaking the idea through for those who chose to act
> similarly. I'd be ok with providing an alias, but I think examples should
> still import the Value name to make the code more clear what V actually
> refers to.
>
> On Monday, 3 April 2017 17:58:43 UTC+10, Adam Johnson wrote:
>>
>> When writing filter expressions using database functions, one is often
>> forced to use django.db.models.Value to wrap raw values to avoid them
>> being interpreted as column references. Value is fairly cumbersome to
>> write when it can appear several times in a complex queryset definition, so
>> it's common to alias it as V when importing. In fact, the database
>> function docs do this exclusively
>> .
>>
>> Because import as is sometimes considered bad style, but the V alias is
>> useful, I'd like to propose django.db.models having a documented
>> internal alias like V = Value. I'm writing here because I can't think of
>> a precedent in Django, except for backwards compatibility reasons.
>>
>> --
>> Adam
>>
> --
> 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/1e4d267e-7441-489f-a2ac-
> c23f34cd246c%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/CAMwjO1G-ukY24jpU_SGoTDTg7aXwOYv81xkgfbjDdZpOnv4zRg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.