Re: [Django] #29522: Serializers are hard to modify

[Django]

#29522: Serializers are hard to modify
--+
 Reporter:  Levi Cameron  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Serialization)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Carlton Gibson):

 * stage:  Unreviewed => Accepted


Comment:

 This sounds reasonable to me. My main thought would be to make sure the
 new hooks a properly documented etc. But yes, good idea.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.6db643e3021778850a02ec0270d7267b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29522: Make Serializers easier to modify (was: Serializers are hard to modify)

[Django]

#29522: Make Serializers easier to modify
--+
 Reporter:  Levi Cameron  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Serialization)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.b1b9c116012a2562917feb04132b55cd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28598: BCC addresses are ignored in the console and file email backends

[Django]

#28598: BCC addresses are ignored in the console and file email backends
-+-
 Reporter:  zngr |Owner:  Josh
 Type:   |  Schneier
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Mail)  |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  mail, bcc| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 >  ...write_message takes in an EmailMessage, not a string.

 Yes, that's right. So they'd need to be some adjustment.

 The trouble with `write_message()` as the hook is that you need to
 essentially reimplement it (or copy and paste the whole thing) in order to
 adjust the formatting.
 As such it's more of a `wontfix` solution.

 The idea I'm trying to communicate is that we add a `format_message()`
 hook, which does just that, separate from the existing `write_message()`
 method, which we just be responsible for the `write()` calls, message
 dividers (etc).

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.8459b7b3db1ac4142592784d9df6b1c8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28598: BCC addresses are ignored in the console and file email backends

[Django]

#28598: BCC addresses are ignored in the console and file email backends
-+-
 Reporter:  zngr |Owner:  Josh
 Type:   |  Schneier
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Mail)  |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  mail, bcc| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 There is (of course) the `wontfix` scenario.

 The "Defining a custom email backend" section begins thus:

 > If you need to change how emails are sent you can write your own email
 backend...

 People wanting BCCs for console or file based backends could just do this.
 We might say it's already documented...

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.8ddb7994d603724b47c4d438d22c3bb7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29559: TransactionTestCase.reset_sequences doesn't reset sequences of auto created ManyToMany models

[Django]

#29559: TransactionTestCase.reset_sequences doesn't reset sequences of auto 
created
ManyToMany models
-+
   Reporter:  Oliver Sauder  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Testing framework  |Version:  master
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 Consider following example:

 {{{
 class Person(models.Model):
 first_name = models.CharField(max_length=20)
 last_name = models.CharField(max_length=20)

 friends = models.ManyToManyField('self')

 class AutoIncrementResetTest(TransactionTestCase):
 reset_sequences = True

 def test_autoincrement_reset1(self):
 p = Person.objects.create(first_name='Jack', last_name='Smith')
 self.assertEqual(p.pk, 1)

 p.friends.add(Person.objects.create(first_name='Jacky',
 last_name='Smith'))
 self.assertEqual(p.friends.through.objects.first().pk, 1)

 def test_autoincrement_reset2(self):
 p = Person.objects.create(first_name='Jack', last_name='Smith')
 self.assertEqual(p.pk, 1)

 p.friends.add(Person.objects.create(first_name='Jacky',
 last_name='Smith'))
 self.assertEqual(p.friends.through.objects.first().pk, 1)
 }}}

 Test **test_autoincrement_reset2** will fail with a much higher primary
 key, indicating that sequence has not been properly reset. Tested this on
 a Postgres database but I assume this error exist on other databases as
 well.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.cf058b066b77ae36d95621d995d0612e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29559: TransactionTestCase.reset_sequences doesn't reset sequences of auto created ManyToMany models

[Django]

#29559: TransactionTestCase.reset_sequences doesn't reset sequences of auto 
created
ManyToMany models
-+-
 Reporter:  Oliver Sauder|Owner:  Oliver
 |  Sauder
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Oliver Sauder):

 * owner:  nobody => Oliver Sauder
 * status:  new => assigned


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.8c78789180bf2897295048bae797d584%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29560: Add an option to django-admin to always colorize output

[Django]

#29560: Add an option to django-admin to always colorize output
-+-
   Reporter:  Nicolas|  Owner:  nobody
  Noé|
   Type: | Status:  new
  Uncategorized  |
  Component:  Core   |Version:  master
  (Management commands)  |
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 With Django management commands, it is currently possible disable colors
 with the `--no-colors` flag.

 What I'd like to have is basically the other side of the coin: a `--force-
 colors` flag that instructs Django to output ANSI color sequences in cases
 it would disable colors by default (typically, when the output is piped to
 another command, as documented).

 My real world use-case is the following one: I have a custom Django
 command to import data. I run this command myself, and I'd like to send a
 colored log (HTML seems perfect for this) to the data curators. I can use
 the https://github.com/theZiz/aha utility for this, but that doesn't work
 since Django disable colors when the output is piped.

 Other *nix commands have a special flag for this exact use-case, for
 example `$ ls --color=always`

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.d98694c8cf5039208c360baefd49d603%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28598: BCC addresses are ignored in the console and file email backends

[Django]

#28598: BCC addresses are ignored in the console and file email backends
-+-
 Reporter:  zngr |Owner:  Josh
 Type:   |  Schneier
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Mail)  |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  mail, bcc| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 > I wonder if adding .format_message() isn't a case of YAGNI or over
 engineering.

 Well, I guess most people won't need it, but that this ticket exists
 suggest some will. Adding a hook to allow subclassing at least allows
 those people to address their issue.
 (Just saying in the docs that "BCCs won't be included" isn't great IMO: it
 offers me no way forward.)

 > ... it will double up ...

 I wouldn't worry about this. If people want to do some set operations in
 their subclass to get **just** the BCCs then they're welcome to.
 All we're doing is providing the hook.

 > Currently write_message also includes '*' * 79...

 I'd leave that where it is. If someone wants to override `write_message()`
 as well then they're welcome.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.572a1a7079050945b31fd4e6fc7857a9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29559: TransactionTestCase.reset_sequences doesn't reset sequences of auto created ManyToMany models

[Django]

#29559: TransactionTestCase.reset_sequences doesn't reset sequences of auto 
created
ManyToMany models
-+-
 Reporter:  Oliver Sauder|Owner:  Oliver
 |  Sauder
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Oliver Sauder):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/10174 PR]

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.697cef57c7c0958953c16173cf95cc80%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29557: add on_commit decorator

[Django]

#29557: add on_commit decorator
-+-
 Reporter:  obayemi  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  transaction  | Triage Stage:
  on_commit decorator|  Unreviewed
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * status:  new => closed
 * resolution:   => wontfix


Comment:

 Hi @obayemi.

 Having considered this more I'm going to go with `wontfix`.

 You're obviously welcome to use a decorator such as this in your own
 project but, using `on_commit()` directly is going to result in
 significantly clearer code.

 In your example, do this:


 {{{
 with transaction.atomic():
 group = Group.objects.create()
 group.users.add(Users.objects.all()
 transaction.on_commit(notify_users)
 }}}

 By shipping a call_on_commit decorator we'd be guiding people towards
 writing less clear code. I think we're not doing anyone any favours there.

 Thanks for the input!

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.e21380270e293506f962c07b546c8e97%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29561: Window Function Lag/Lead supported on Filter (Not equal) for FloatField

[Django]

#29561: Window Function Lag/Lead supported on Filter (Not equal) for FloatField
-+-
   Reporter: |  Owner:  nobody
  gabriellima|
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  2.0
  layer (models, ORM)|   Keywords:  window functions
   Severity:  Normal |  database
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I'd like to be able to reproduce the following example in Django, but on
 the Temperature column
 (https://fle.github.io/detect-value-changes-between-successive-lines-with-
 postgresql.html)


 Given a table

 db=> SELECT * FROM weather ORDER BY day DESC;

 ||= day ||= temperature ||= rainy =||
 || 2014-04-08 || 20.0 || f
 ||2014-04-07 ||  20.0 || f
 ||2014-04-06 ||  16.0 || t
 ||2014-04-05 ||  16.0 || t
 ||2014-04-04 ||  16.0 || t
 ||2014-04-03 ||  22.0 || f
 ||2014-04-02 ||  22.0 || f
 ||2014-04-01 || 22.0 || t


 I'd like to show dates only if the temperature changed:

 ||= day ||= temperature =||
 ||2014-04-08 || 20.0||
 ||2014-04-06 || 16.0||
 ||2014-04-03 || 22.0||


 On pure PostgreSQL, this translates to:

 {{{#!sql
 SELECT
 w1.day, w1.temperature
 FROM
 (SELECT
 w2.day,
 w2.temperature,
 lead(w2.temperature) OVER (ORDER BY w2.day DESC) as prev_temp
  FROM
 weather w2
  ORDER BY
 w2.day DESC) as w1
 WHERE
 w1.temp IS DISTINCT FROM w1.prev_temp
 ORDER BY
 w1.day DESC;
 }}}

 I could accomplish the inner query by using the new Window Functions:

 {{{#!python
 Weather.objects.annotate(prev_temp=Window(expression=Lead('temperature'),
 order_by=F('day').desc()))
 }}}

 Now my problem is use this annotation to filter only when temperature
 differs from prev_temp
 (in order to accomplish something similar to the "temperature IS DISTINCT
 FROM prev_temp")

 When I try to use the available filters, the following errors occurs:

 {{{#!python
 Weather.objects.annotate(prev_temp=Window(expression=Lead('temperature'),
 
order_by=F('day').desc())).order_by('-day').filter(temperature__ne=F('prev_temp'))
 }}}

 Gives the error:
 {{{#!python
 FieldError: Unsupported lookup 'ne' for FloatField or join on the field
 not permitted.
 }}}

 Another try:

 {{{#!python
 Weather.objects.annotate(prev_temp=Window(expression=Lead('temperature'),
 
order_by=F('day').desc())).order_by('-day').filter(~Q(temperature=F('prev_temp'
 }}}
 Gives the error:
 {{{#!python
 ProgrammingError: window functions are not allowed in WHERE
 }}}

 It's in fact a PostgreSQL error, because the generated SQL query tries to
 pass the LAG function inside the where clause.

 How may I accomplish that, even if I have to use the extra fields, or even
 RawSQL class ?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/054.5c03407b8839cd4cefc11b9f577d6b4a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28598: BCC addresses are ignored in the console and file email backends

[Django]

#28598: BCC addresses are ignored in the console and file email backends
-+-
 Reporter:  zngr |Owner:  Josh
 Type:   |  Schneier
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Mail)  |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  mail, bcc| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Josh Schneier):

 To be clear `write_message` takes in an `EmailMessage`, not a string.
 Curious what you think about documenting `write_message` as the hook given
 that?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.b6d33178721b4a63ba4b84a11b505d92%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26720: migration optimizer can produce operations that references removed models under certain circumstances

[Django]

#26720: migration optimizer can produce operations that references removed 
models
under certain circumstances
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Tim
 |  Graham 
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

 * owner:  (none) => Tim Graham 
 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"ad82900ad94ed4bbad050b9993373dafbe66b610" ad82900a]:
 {{{
 #!CommitTicketReference repository=""
 revision="ad82900ad94ed4bbad050b9993373dafbe66b610"
 Fixed #26720 -- Prevented invalid CreateModel optimizations of related
 fields.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.6bd95818fb0c1148b4a5c1a7fd54ce3c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27768: makemigrations uses unnecessary AddField for ForeignKey depending on model name

[Django]

#27768: makemigrations uses unnecessary AddField for ForeignKey depending on 
model
name
-+-
 Reporter:  Ed Morley|Owner:  Ed Morley
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"d3a935f01f6cb36d21b09d81c5f022a3a5116ab0" d3a935f0]:
 {{{
 #!CommitTicketReference repository=""
 revision="d3a935f01f6cb36d21b09d81c5f022a3a5116ab0"
 Refs #27768 -- Reversed order of optimized and in-between operations.

 Operations can only be optimized through if they don't reference any of
 the
 state the operation they are compared against defines or alters, so it's
 safe to reverse the order.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.d387b1e70be9ff02d7a8b9d4d04d12d2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27845: Possible Migration Optimizer Strategy Improvement

[Django]

#27845: Possible Migration Optimizer Strategy Improvement
-+-
 Reporter:  Raphael Gaschignard  |Owner:  Simon
 Type:   |  Charette
  Cleanup/optimization   |   Status:  closed
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"37cafbfb791b2295b8c36cdabbdef0e5d951a64e" 37cafbfb]:
 {{{
 #!CommitTicketReference repository=""
 revision="37cafbfb791b2295b8c36cdabbdef0e5d951a64e"
 Fixed #27845 -- Allowed both right and left optimizations of operations.

 Thanks Raphael Gaschignard for the suggestion.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.db08081e9abc2e726fc8843ad4a7a47e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27768: makemigrations uses unnecessary AddField for ForeignKey depending on model name

[Django]

#27768: makemigrations uses unnecessary AddField for ForeignKey depending on 
model
name
-+-
 Reporter:  Ed Morley|Owner:  Ed Morley
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"a97845a823c86b1d6e65af70fbce64e6e747e081" a97845a8]:
 {{{
 #!CommitTicketReference repository=""
 revision="a97845a823c86b1d6e65af70fbce64e6e747e081"
 Fixed #27768 -- Allowed migration optimization of CreateModel order.

 Thanks Ed Morley from Mozilla for the tests.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.1d929df152cf9b4a6cd221e572d9ea3b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29561: Window Function Lag/Lead supported on Filter (Not equal) for FloatField

[Django]

#29561: Window Function Lag/Lead supported on Filter (Not equal) for FloatField
-+-
 Reporter:  Gabriel Oliveira |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  window functions | Triage Stage:
  database   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Gabriel Oliveira:

Old description:

> I'd like to be able to reproduce the following example in Django, but on
> the Temperature column
> (https://fle.github.io/detect-value-changes-between-successive-lines-
> with-postgresql.html)
>

> Given a table
>
> db=> SELECT * FROM weather ORDER BY day DESC;
>
> ||= day ||= temperature ||= rainy =||
> || 2014-04-08 || 20.0 || f
> ||2014-04-07 ||  20.0 || f
> ||2014-04-06 ||  16.0 || t
> ||2014-04-05 ||  16.0 || t
> ||2014-04-04 ||  16.0 || t
> ||2014-04-03 ||  22.0 || f
> ||2014-04-02 ||  22.0 || f
> ||2014-04-01 || 22.0 || t
>

> I'd like to show dates only if the temperature changed:
>
> ||= day ||= temperature =||
> ||2014-04-08 || 20.0||
> ||2014-04-06 || 16.0||
> ||2014-04-03 || 22.0||
>

> On pure PostgreSQL, this translates to:
>
> {{{#!sql
> SELECT
> w1.day, w1.temperature
> FROM
> (SELECT
> w2.day,
> w2.temperature,
> lead(w2.temperature) OVER (ORDER BY w2.day DESC) as prev_temp
>  FROM
> weather w2
>  ORDER BY
> w2.day DESC) as w1
> WHERE
> w1.temp IS DISTINCT FROM w1.prev_temp
> ORDER BY
> w1.day DESC;
> }}}
>
> I could accomplish the inner query by using the new Window Functions:
>
> {{{#!python
> Weather.objects.annotate(prev_temp=Window(expression=Lead('temperature'),
> order_by=F('day').desc()))
> }}}
>
> Now my problem is use this annotation to filter only when temperature
> differs from prev_temp
> (in order to accomplish something similar to the "temperature IS DISTINCT
> FROM prev_temp")
>
> When I try to use the available filters, the following errors occurs:
>
> {{{#!python
> Weather.objects.annotate(prev_temp=Window(expression=Lead('temperature'),
> order_by=F('day').desc())).order_by('-day').filter(temperature__ne=F('prev_temp'))
> }}}
>
> Gives the error:
> {{{#!python
> FieldError: Unsupported lookup 'ne' for FloatField or join on the field
> not permitted.
> }}}
>
> Another try:
>
> {{{#!python
> Weather.objects.annotate(prev_temp=Window(expression=Lead('temperature'),
> order_by=F('day').desc())).order_by('-day').filter(~Q(temperature=F('prev_temp'
> }}}
> Gives the error:
> {{{#!python
> ProgrammingError: window functions are not allowed in WHERE
> }}}
>
> It's in fact a PostgreSQL error, because the generated SQL query tries to
> pass the LAG function inside the where clause.
>
> How may I accomplish that, even if I have to use the extra fields, or
> even RawSQL class ?

New description:

 I'd like to be able to reproduce the following example in Django, but on
 the Temperature column
 (https://fle.github.io/detect-value-changes-between-successive-lines-with-
 postgresql.html)


 Given a table

 db=> SELECT * FROM weather ORDER BY day DESC;

 ||= day ||= temperature ||= rainy =||
 || 2014-04-08 || 20.0 || f
 ||2014-04-07 ||  20.0 || f
 ||2014-04-06 ||  16.0 || t
 ||2014-04-05 ||  16.0 || t
 ||2014-04-04 ||  16.0 || t
 ||2014-04-03 ||  22.0 || f
 ||2014-04-02 ||  22.0 || f
 ||2014-04-01 || 22.0 || t


 I'd like to show dates only if the temperature changed:

 ||= day ||= temperature =||
 ||2014-04-08 || 20.0||
 ||2014-04-06 || 16.0||
 ||2014-04-03 || 22.0||


 On pure PostgreSQL, this translates to:

 {{{#!sql
 SELECT
 w1.day, w1.temperature
 FROM
 (SELECT
 w2.day,
 w2.temperature,
 lead(w2.temperature) OVER (ORDER BY w2.day DESC) as prev_temp
  FROM
 weather w2
  ORDER BY
 w2.day DESC) as w1
 WHERE
 w1.temp IS DISTINCT FROM w1.prev_temp
 ORDER BY
 w1.day DESC;
 }}}

 I could accomplish the inner query by using the new Window Functions:

 {{{#!python
 Weather.objects.annotate(prev_temp=Window(expression=Lead('temperature'),
 order_by=F('day').desc()))
 }}}

 Now my problem is use this annotation to filter only when temperature
 differs from prev_temp
 (in order to accomplish something similar to the "temperature IS DISTINCT
 FROM prev_temp")

 When I try to 

Re: [Django] #28598: BCC addresses are ignored in the console and file email backends

[Django]

#28598: BCC addresses are ignored in the console and file email backends
-+-
 Reporter:  zngr |Owner:  Josh
 Type:   |  Schneier
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Mail)  |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  mail, bcc| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Josh Schneier):

 I have a cursory implementation of your solution which is simple enough.

 My hesitation is that this and the other opened issue seems more like
 users wanting to ensure that their code is doing precisely what they are
 telling it to do and then not realizing that BCC is not included in the
 actual MIME text which is what we are printing
 ([https://github.com/mattupstate/flask-mail/pull/119 I speak from
 experience]). Or that they want to be able to access it and expect to see
 ''everything'' since these backends are explicitly for development.

 How about we add the hook and document BCC explicitly or that the default
 implementations return the MIME text?

 The no-BCC-in-MIME is very much part of the black box that is the email
 spec which we shouldn't be reproducing in the docs but it is confusing
 when encountered in this context.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.8d5822a1a6b7e85c39abac910d765119%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28598: BCC addresses are ignored in the console and file email backends

[Django]

#28598: BCC addresses are ignored in the console and file email backends
-+-
 Reporter:  zngr |Owner:  Josh
 Type:   |  Schneier
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Mail)  |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  mail, bcc| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Josh Schneier):

 I updated the PR with a provisional patch. I am also okaying `wontfix`-ing
 this.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.45ed68d65a272388b67f8539bdaba2aa%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28478: Make DiscoverRunner skip creating a test database if not needed

[Django]

#28478: Make DiscoverRunner skip creating a test database if not needed
--+
 Reporter:  Tim Graham|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Simon Charette):

 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/10175 PR]

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.40436b69a686181617424b54b7814954%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24810: Reopen database connection automatically when no transaction is active

[Django]

#24810: Reopen database connection automatically when no transaction is active
-+-
 Reporter:  Aymeric Augustin |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Marti Raudsepp):

 * cc: Marti Raudsepp (added)


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.e1ba60aa3e9e87054ad3aef50e4834b4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29559: TransactionTestCase.reset_sequences doesn't reset sequences of auto created ManyToMany models

[Django]

#29559: TransactionTestCase.reset_sequences doesn't reset sequences of auto 
created
ManyToMany models
-+-
 Reporter:  Oliver Sauder|Owner:  Oliver
 |  Sauder
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Unreviewed => Ready for checkin


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.69be5f15a817dab6d86a442a2eab1955%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29559: TransactionTestCase.reset_sequences doesn't reset sequences of auto created ManyToMany models

[Django]

#29559: TransactionTestCase.reset_sequences doesn't reset sequences of auto 
created
ManyToMany models
-+-
 Reporter:  Oliver Sauder|Owner:  Oliver
 |  Sauder
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"a07a49ee3295061f384d98d520a565658dd064b8" a07a49ee]:
 {{{
 #!CommitTicketReference repository=""
 revision="a07a49ee3295061f384d98d520a565658dd064b8"
 Fixed #29559 -- Fixed TransactionTestCase.reset_sequences for auto-created
 m2m through models.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.df190a0bd7d2d29f86e24c1e307190fa%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #9804: sqlflush fails for ManyToMany with inherited intermediary

[Django]

#9804: sqlflush fails for ManyToMany with inherited intermediary
-+-
   Reporter:  jdimov |Owner:  nobody
   Type: |   Status:  closed
  Component:  Database layer |  Version:  1.0
  (models, ORM)  |
   Severity: |   Resolution:  fixed
   Keywords:  ManyToMany, sqlflush,  | Triage Stage:  Accepted
  sequence_list  |
  Has patch:  0  |  Needs documentation:  0
Needs tests:  0  |  Patch needs improvement:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"4d98b9d729fa7f2525f346fbaf180030c3c3a5f8" 4d98b9d]:
 {{{
 #!CommitTicketReference repository=""
 revision="4d98b9d729fa7f2525f346fbaf180030c3c3a5f8"
 Refs #9804 -- Fixed test for sequence reset of M2M with inherited through
 model.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.f04f53ed234dea94147b92cfe48b5641%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.