Re: [Django] #14904: TextField with unique (or in unique_together) constraint breaks for large inputs in Postgres

[Django]

#14904: TextField with unique (or in unique_together) constraint breaks for 
large
inputs in Postgres
-+-
 Reporter:  jorn |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgresql, index,   | Triage Stage:  Accepted
  textfield  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Sarah Messer):

 Have also observed this with Django 1.8 and postgres 9.3

 I'm linking references for fixes / workarounds found in a quick search:
 * http://stackoverflow.com/questions/20725671/how-to-truncate-column-in-
 order-to-create-indexes
 * https://www.postgresql.org/message-
 id/AANLkTikG_nHARKr9qeQXpS7Q6QXgJvuFUi6Wxpd0o7H7%40mail.gmail.com
 * https://www.postgresql.org/docs/current/static/indexes-opclass.html

 At the moment, it looks like any workaround involves writing some raw SQL.
 Digging through Django's code, indices are created by
 django.db.backends.base.schema.BaseDatabaseSchemaEditor._sql_create_index()
 That's pretty far outside the public API.

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

Re: [Django] #27193: ORDER BY clause not included in subqueries using select_for_update()

[Django]

#27193: ORDER BY clause not included in subqueries using select_for_update()
-+-
 Reporter:  sqwishy  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/7319 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.7042409b5650b722953426a4466817fa%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27186: Cannot change CheckboxSelectMultiple, FileInput, MultiWidget, SplitDateTimeWidget, and SelectDateWidget with model field default since Django 1.10.1

[Django]

#27186: Cannot change CheckboxSelectMultiple, FileInput, MultiWidget,
SplitDateTimeWidget, and SelectDateWidget with model field default since
Django 1.10.1
-+--
 Reporter:  Michael Käufl|Owner:  Tim Graham
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.10
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by Tim Graham ):

 In [changeset:"f23c03ebc81c64b8b41f3aae0dbe93fc283cc43d" f23c03e]:
 {{{
 #!CommitTicketReference repository=""
 revision="f23c03ebc81c64b8b41f3aae0dbe93fc283cc43d"
 [1.10.x] Refs #27186 -- Fixed model form default fallback for
 CheckboxSelectMultiple.

 Backport of 87c5e7efebd040aef0f0479ccf86877155bb5cea from master
 }}}

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

Re: [Django] #27186: Cannot change CheckboxSelectMultiple, FileInput, MultiWidget, SplitDateTimeWidget, and SelectDateWidget with model field default since Django 1.10.1

[Django]

#27186: Cannot change CheckboxSelectMultiple, FileInput, MultiWidget,
SplitDateTimeWidget, and SelectDateWidget with model field default since
Django 1.10.1
-+--
 Reporter:  Michael Käufl|Owner:  Tim Graham
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.10
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by Tim Graham):

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


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

Re: [Django] #27300: makemigrations --dry-run -v 3 on Python 3 writes byte string to stdout

[Django]

#27300: makemigrations --dry-run -v 3 on Python 3 writes byte string to stdout
-+-
 Reporter:  Markus Holtermann|Owner:  Markus
 |  Holtermann
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:  1.10
  commands)  |
 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:  Accepted => 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.f017d4d39a34f75f362ff93a496a2ef9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27186: Cannot change CheckboxSelectMultiple, FileInput, MultiWidget, SplitDateTimeWidget, and SelectDateWidget with model field default since Django 1.10.1

[Django]

#27186: Cannot change CheckboxSelectMultiple, FileInput, MultiWidget,
SplitDateTimeWidget, and SelectDateWidget with model field default since
Django 1.10.1
-+--
 Reporter:  Michael Käufl|Owner:  Tim Graham
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.10
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by GitHub ):

 In [changeset:"87c5e7efebd040aef0f0479ccf86877155bb5cea" 87c5e7e]:
 {{{
 #!CommitTicketReference repository=""
 revision="87c5e7efebd040aef0f0479ccf86877155bb5cea"
 Refs #27186 -- Fixed model form default fallback for
 CheckboxSelectMultiple.
 }}}

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

Re: [Django] #26541: Add a DatabaseFeatures.supports_transactions() method for MySQL

[Django]

#26541: Add a DatabaseFeatures.supports_transactions() method for MySQL
-+-
 Reporter:  Marcin Nowak |Owner:  felixxm
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * stage:  Accepted => 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.12afc41c8458e7e519cd8f467d221d3f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27294: Document fields in UserCreationForm

[Django]

#27294: Document fields in UserCreationForm
-+-
 Reporter:  Lewis Cowles |Owner:  Lewis
 Type:   |  Cowles
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  docs,user,contrib| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"fb9f3962756ed80ec8ecec8ec2095ee6bca49efd" fb9f3962]:
 {{{
 #!CommitTicketReference repository=""
 revision="fb9f3962756ed80ec8ecec8ec2095ee6bca49efd"
 [1.10.x] Fixed #27294 -- Documented UserCreationForm's fields.

 Backport of 1d25eb9688f1a245737490dccf8ba54b6c907052 from master
 }}}

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

Re: [Django] #27294: Document fields in UserCreationForm

[Django]

#27294: Document fields in UserCreationForm
-+-
 Reporter:  Lewis Cowles |Owner:  Lewis
 Type:   |  Cowles
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  docs,user,contrib| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"1d25eb9688f1a245737490dccf8ba54b6c907052" 1d25eb9]:
 {{{
 #!CommitTicketReference repository=""
 revision="1d25eb9688f1a245737490dccf8ba54b6c907052"
 Fixed #27294 -- Documented UserCreationForm's 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/073.d85b6b2b24b8223b6b19d757138276f4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27300: makemigrations --dry-run -v 3 on Python 3 writes byte string to stdout

[Django]

#27300: makemigrations --dry-run -v 3 on Python 3 writes byte string to stdout
-+-
 Reporter:  Markus Holtermann|Owner:  Markus
 |  Holtermann
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:  1.10
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz):

 Here's an alternative [https://github.com/django/django/pull/7329 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.9854ad87be42936af6c845ed757fb97c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26940: makemessages incorrectly configured as not requiring settings

[Django]

#26940: makemessages incorrectly configured as not requiring settings
-+-
 Reporter:  Jorge Romero |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  translations | 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/066.62ba512b50fb5a44af3f331dfa04d261%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27210: smtp EmailBackend doesn't honor fail_silently=True when receiving a socket level connection error

[Django]

#27210: smtp EmailBackend doesn't honor fail_silently=True when receiving a 
socket
level connection error
-+-
 Reporter:  Tom Hendrikx |Owner:  Vesteinn
 |  Snaebjarnarson
 Type:  Bug  |   Status:  closed
Component:  Core (Mail)  |  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
-+-

Comment (by GitHub ):

 In [changeset:"f6fe8ecc10a3d88470e25fe6ebc61122154653f0" f6fe8ecc]:
 {{{
 #!CommitTicketReference repository=""
 revision="f6fe8ecc10a3d88470e25fe6ebc61122154653f0"
 Refs #27210 -- Fixed isolation of test_fail_silently_on_connection_error.

 The test wouldn't pass if a mail server is running on the system.
 }}}

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

Re: [Django] #27297: Non-deterministic infinite AlterField migrations created for foreign key

[Django]

#27297: Non-deterministic infinite AlterField migrations created for foreign key
+
 Reporter:  Daniel Musketa  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.10
 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
+

Comment (by Daniel Musketa):

 Replying to [comment:3 Baptiste Mispelon]:
 > Is it possible you changed the name of `Model1` in the same way?

 Yes, you’re absolutely right. In the actual project there was first

 {{{class adress(models.Model)}}} (sic!), then
 {{{class address(models.Model)}}} and then finally
 {{{class Address(models.Model)}}}.

 In the migration files it looks like this:

 {{{
 class Migration(migrations.Migration):

 initial = True

 dependencies = [
 ]

 operations = [
 migrations.CreateModel(
 name='adress',
 fields=[
 ('id', models.AutoField(auto_created=True,
 primary_key=True, serialize=False, verbose_name='ID')),
 ],
 ),
 ]
 }}}

 and then

 {{{
 class Migration(migrations.Migration):

 dependencies = [
 ('app1', '0001_initial'),
 ]

 operations = [
 migrations.RenameModel(
 old_name='adress',
 new_name='address',
 ),
 ]
 }}}

 But then no new change is detected. I tested a rename from {{{adress}}} to
 {{{Address}}} which results in a capitalized {{{new_name='Address',}}} and
 everything should be fine.

 So, the actual problem might be the rename from a lowercase to capfirst
 model name. This is not detected by makemigrations which seems to compare
 everything {{{.lower()}}}’d.

 This doesn’t explain though why changes are detected in only some of my
 for loop {{{makemigrations}}} runs. ;-)

 Propably related to #22608?

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

Re: [Django] #26940: makemessages incorrectly configured as not requiring settings

[Django]

#26940: makemessages incorrectly configured as not requiring settings
-+-
 Reporter:  Jorge Romero |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  translations | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz):

 Here's the [https://github.com/django/django/pull/7328 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/066.8ba9f9848197e04d6548616fb1a5b165%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27300: makemigrations --dry-run -v 3 on Python 3 writes byte string to stdout

[Django]

#27300: makemigrations --dry-run -v 3 on Python 3 writes byte string to stdout
-+-
 Reporter:  Markus Holtermann|Owner:  Markus
 |  Holtermann
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:  1.10
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz):

 * easy:  1 => 0
 * stage:  Unreviewed => Accepted


Comment:

 The fact that `MigrationWriter.as_string` is returning a bytestring is
 IMHO a violation of the general principle of `decode` as soon as possible,
 `encode` as late as possible, which is a good rule to follow regarding
 string handling. I'd rather see a patch that removes the final
 `encode("utf8")` in the `as_string` method.

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

Re: [Django] #27301: Better handling of errors that are not pickleable when testing in parallel

[Django]

#27301: Better handling of errors that are not pickleable when testing in 
parallel
-+-
 Reporter:  Adam Wróbel  |Owner:  (none)
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Testing framework|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  testrunner parallel  | Triage Stage:
  pickle |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * status:  assigned => new
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * owner:  Tim Graham => (none)
 * needs_docs:   => 0
 * type:  Uncategorized => Cleanup/optimization


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

[Django] #27301: Better handling of errors that are not pickleable when testing in parallel

[Django]

#27301: Better handling of errors that are not pickleable when testing in 
parallel
--+
 Reporter:  Adam Wróbel   |  Owner:  Tim Graham
 Type:  Uncategorized | Status:  assigned
Component:  Testing   |Version:  1.10
  framework   |
 Severity:  Normal|   Keywords:  testrunner parallel pickle
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 When running test in parallel the tests results are communicated between
 processes in serialized form. Unfortunately not all test errors are
 serializable using `pickle` module.

 Django currently detects errors that fail `pickle.dumps`, reports them to
 `STDERR` and raises exception that interrupts test runner.

 This ticket has two parts:

 The first is a minor enhancement. In addition to detecting `pickle.dumps`
 errors also detect `pickle.loads` errors. I've implemented it in a
 [https://github.com/django/django/pull/7325 Github PR #7325].

 The second is a proposal to instead of raising pickling exception that
 interrupts tests and displays useless
 `multiprocessing.pool.RemoteTraceback` wrap the error type and message in
 some kind of `UnpickleableError` container and pass it to parent process
 with the usual `addError`/`addFailure`/`addSubTest`/`addExpectedFailure`
 methods. This will let the test suite continue, display final error
 statistics and perform teardown. This is especially important for
 `addExpectedFailure` which currently stops the entire suite if the
 expected error is unpickleable (my actual use case).

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

Re: [Django] #27300: makemigrations --dry-run -v 3 on Python 3 writes byte string to stdout

[Django]

#27300: makemigrations --dry-run -v 3 on Python 3 writes byte string to stdout
-+-
 Reporter:  Markus Holtermann|Owner:  Markus
 |  Holtermann
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:  1.10
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Markus Holtermann):

 * has_patch:  0 => 1


Comment:

 PR: https://github.com/django/django/pull/7326

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

[Django] #27300: makemigrations --dry-run -v 3 on Python 3 writes byte string to stdout

[Django]

#27300: makemigrations --dry-run -v 3 on Python 3 writes byte string to stdout
-+-
   Reporter:  Markus |  Owner:  Markus Holtermann
  Holtermann |
   Type:  Bug| Status:  assigned
  Component:  Core   |Version:  1.10
  (Management commands)  |
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 On Python 3 `makemigrations --dry-run -v 3` outputs the content of the
 migration file as a byte string with `b"...\n..."` instead of a properly
 decoded unicode string.

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

Re: [Django] #27297: Non-deterministic infinite AlterField migrations created for foreign key

[Django]

#27297: Non-deterministic infinite AlterField migrations created for foreign key
+
 Reporter:  Daniel Musketa  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.10
 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
+

Comment (by Baptiste Mispelon):

 I think the issue might be caused by the `name='model1',` in the initial
 migration.

 When I generate the migrations, I get `name='Model1',` (notice the
 difference in the capitalization of the model).

 How did you generate the initial migration?


 I noticed that if I start with `class model1(models.Model): ...`, create
 the initial migration, change to `class Model1(models.Model): ...`, then
 `makemigrations` won't detect any changes. Is it possible you changed the
 name of `Model1` in the same way?

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

Re: [Django] #27055: Model form with geometry widgets has invalid html

[Django]

#27055: Model form with geometry widgets has invalid html
-+-
 Reporter:  Antonis  |Owner:  Antonis
  Christofides   |  Christofides
 Type:  Bug  |   Status:  assigned
Component:  GIS  |  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 Antonis Christofides):

 * has_patch:  1 => 0


Comment:

 Summarizing yesterday's discussion with claudep on IRC, the fake div hack
 is, ehm, a hack, and we prefer to find a better way to do it. We will
 break backwards compatibility with {% block map_css %}. The
 ".olControlEditingToolbar .olControlModifyFeatureItemActive" section of
 the css can be moved into a static file, using a relative URL for
 background-image. The rest of the css can be moved to the "style"
 attribute of the HTML elements.

 Question (which I asked on IRC but missed any response): If we want to
 follow CSP and get rid of inline css (and inline JS) altogether, how are
 we going to specify this dynamic CSS?

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

Re: [Django] #26315: Allow call_command() to accept a Command object as the first argument

[Django]

#26315: Allow call_command() to accept a Command object as the first argument
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:  New feature  |   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
-+-

Comment (by Claude Paroz):

 Note that in your problematic case, the code is directly calling
 `graph_models.Command().execute(*apps, **options)` instead of using
 `call_command` which takes care of populating all default arguments.

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

Re: [Django] #26315: Allow call_command() to accept a Command object as the first argument

[Django]

#26315: Allow call_command() to accept a Command object as the first argument
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:  New feature  |   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:  new => closed
 * resolution:   => fixed


Comment:

 Please open a new ticket rather than reopening one that's already been
 released. Thanks.

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

Re: [Django] #26315: Allow call_command() to accept a Command object as the first argument

[Django]

#26315: Allow call_command() to accept a Command object as the first argument
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:  New feature  |   Status:  new
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 Melvyn Sopacua):

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


Comment:

 Replying to [comment:4 Tim Graham ]:
 > In [changeset:"1845bc1d1007751a7f65c66aeddc35f032f6bf41" 1845bc1d]:
 > {{{
 > #!CommitTicketReference repository=""
 revision="1845bc1d1007751a7f65c66aeddc35f032f6bf41"
 > Refs #26315 -- Cleaned up argparse options in commands.
 >
 > * Removed type coercion. Options created by argparse are already coerced
 >   to the correct type.
 > * Removed fallback default values. Options created by argparse already
 >   have a default value.
 > * Used direct indexing. Options created by argparse are always set. This
 >   eliminates the need to use dict.get().
 > }}}

 The final statement is untrue. Various management commands from reusable
 apps are now failing (most notably Mezzanine and django-extensions),
 because they invoke:

 {{{#!python
 call_command('name', options_i_know_about=value)
 }}}

 Evident
 
[https://bitbucket.org/stephenmcd/mezzanine/src/82939507b6dc2519161db6ee49fec1bd194520de/mezzanine/core/management/commands/createdb.py?at=default
 =file-view-default#createdb.py-48 here].

 This means those commands blow up on `options['no_color']` with a
 `KeyError`. When the exception is caught and reformatted things get worse,
 like
 
[https://bitbucket.org/stephenmcd/mezzanine/src/82939507b6dc2519161db6ee49fec1bd194520de/mezzanine/utils/docs.py?at=default
 =file-view-default#docs.py-259 here], where the resulting error message
 (Couldn't build model_graph, graph_models failed on: 'no_color') made me
 think of lacking LCMS support in Pillow.

 I'm proposing a temporary fix to check if all "options created by
 argparse" - in fact being the options that should always be supported on
 any management command are in fact present in the passed in options dict
 and if not issue a `DeprecationWarning` that calling call_command()
 without passing the original options dictionary will be unsupported in the
 future.

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

Re: [Django] #27290: Email validation doesn't check length

[Django]

#27290: Email validation doesn't check length
---+--
 Reporter:  kyoki  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  1.10
 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
---+--

Comment (by Moritz Sichert):

 This is possibly a duplicate of #26423. The consensus there is to use less
 complex HTML5 validation rules instead of trying to validate an address
 exactly according to the RFCs.

 Also one problem I can immediately think of is how you would count the
 length of unicode characters: For the purposes of validation should the
 length of `ä@foo` be 5 or 6?

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

Re: [Django] #27290: Email validation doesn't check length

[Django]

#27290: Email validation doesn't check length
---+--
 Reporter:  kyoki  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  1.10
 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 Lewis Cowles):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Replying to [ticket:27290 kyoki]:
 > Django's {{{ validate_email }}}/{{{EmailValidator}}} doesn't properly
 check the length of emails as defined in RFC3696. The local part should be
 restricted to 64 characters and the domain to 255. The overall email
 address length is restricted to 256 characters in RFC 2821.

 The maximum length of an email address is 254 as in RFC 5321 it states
 "The maximum total length of a reverse-path or forward-path is 256
 characters". With two chars taken up, 254 is all we are left with.

 **Sources:**
 http://stackoverflow.com/questions/386294/what-is-the-maximum-length-of-a
 -valid-email-address
 http://www.rfc-editor.org/errata_search.php?rfc=3696=1690

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

Re: [Django] #27298: Unclear "after each test" wording in the documentation

[Django]

#27298: Unclear "after each test" wording in the documentation
---+--
 Reporter:  Victor Porton  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.10
 Severity:  Normal |   Resolution:  wontfix
 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 Claude Paroz):

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


Comment:

 Agreed with Tim.

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