date:20160816

[Django] #27069: Documentation for what's possible to import as _

2016-08-16 Thread Django

#27069: Documentation for what's possible to import as _
--+
 Reporter:  lovmat|  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+
 Had an issue where I attempted to import pgettext as _ which failed.
 Thought I could add some documentation which might be helpful for someone
 else.

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

Re: [Django] #27069: Documentation for what's possible to import as _

2016-08-16 Thread Django

#27069: Documentation for what's possible to import as _
-+-
 Reporter:  lovmat   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  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 lovmat):

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


Comment:

 https://github.com/lovmat/django/tree/ticket_27069

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

Re: [Django] #27067: Deprecate string_concat

2016-08-16 Thread Django

#27067: Deprecate string_concat
--+
 Reporter:  lovmat|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Internationalization  |  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 claudep):

 * stage:  Unreviewed => Accepted


Comment:

 I'm fully for deprecating `string_concat` if we have a nice replacement. I
 guess the first step to demonstrate the feasibility is to do the
 replacement for Django usage itself.

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

Re: [Django] #27029: invalid email addresses input django validate_email

2016-08-16 Thread Django

#27029: invalid email addresses input django validate_email
-+-
 Reporter:  RaminFP  |Owner:  Ramin
 |  Farajpour Cami
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  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 claudep):

 * needs_better_patch:  0 => 1


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

Re: [Django] #27029: invalid email addresses input django validate_email

2016-08-16 Thread Django

#27029: invalid email addresses input django validate_email
-+-
 Reporter:  RaminFP  |Owner:  Ramin
 |  Farajpour Cami
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  master
 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 claudep):

 * stage:  Ready for checkin => Accepted


Comment:

 I just tested Firefox and Chrome email validation, and they don't accept
 non-ASCII in the local part.

 In any case, I think we should provide both validators (ASCII-only and
 Unicode). It might be a bit too soon to unconditionally allow Unicode in
 emails.

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

Re: [Django] #27068: Acquire form's initial data more consistently

2016-08-16 Thread Django

#27068: Acquire form's initial data more consistently
---+
 Reporter:  jdufresne  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Forms  |  Version:  master
 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 claudep):

 * stage:  Unreviewed => Accepted


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

Re: [Django] #26423: Make EmailValidator use HTML5 validation rather than more complicated regular expressions

2016-08-16 Thread Django

#26423: Make EmailValidator use HTML5 validation rather than more complicated
regular expressions
--+
 Reporter:  timgraham |Owner:  cjbcross
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Core (Other)  |  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
--+

Comment (by claudep):

 I suggest that Unicode validation be discussed separately in #27029.

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

Re: [Django] #27069: Documentation for what's possible to import as _

2016-08-16 Thread Django

#27069: Documentation for what's possible to import as _
--+
 Reporter:  lovmat|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 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 claudep):

 * stage:  Unreviewed => Accepted


Comment:

 Please make it a pull request.

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

Re: [Django] #27067: Deprecate string_concat

2016-08-16 Thread Django

#27067: Deprecate string_concat
--+
 Reporter:  lovmat|Owner:  lovmat
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Internationalization  |  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 lovmat):

 * owner:  nobody => lovmat
 * status:  new => assigned


Comment:

 https://github.com/lovmat/django/tree/ticket_27067
 Todo: Documentation
 Depends on: #26866 / PR 7087

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

Re: [Django] #27067: Deprecate string_concat

2016-08-16 Thread Django

#27067: Deprecate string_concat
--+
 Reporter:  lovmat|Owner:  lovmat
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Internationalization  |  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
--+

Comment (by claudep):

 I think I'm totally convinced now :-)

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

Re: [Django] #26866: Lazy variant of string format

2016-08-16 Thread Django

#26866: Lazy variant of string format
--+
 Reporter:  lovmat|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Internationalization  |  Version:  master
 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 claudep):

 * needs_better_patch:  1 => 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/064.bfc9a2ff6dc373f598fc203a2f61e226%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #19580: Unify reverse foreign key and m2m unsaved model querying

2016-08-16 Thread Django

#19580: Unify reverse foreign key and m2m unsaved model querying
-+-
 Reporter:  akaariai |Owner:  akuzminov
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-

Comment (by timgraham):

 I left comments for improvement on the rebased
 [https://github.com/django/django/pull/7098 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.0e0a0f6f37ebbf9062dacb73228949ec%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26983: Boolean filter "field__isnull=False" not working with ForeignKey with to_field

2016-08-16 Thread Django

Comment (by lamby):

After writing a testcase (available here:
https://gist.github.com/lamby/394b712e9e9ff1e868a20e67d4ba482b/raw) "git
bisect" told me that it was indeed fixed with the above change.
Investigating more, what happened was that I was applying the patch
against `RelatedIn`instead of `RelatedLookupMixin`. Apologies for the
noise there.

''However'', I am still correct in that the bug is not strictly `to_field`
specific as it affects this `primary_key` case. Therefore, I suggest:

* You update the release documentation, etc. to reflect this
* You add my test (or similar) to prevent a regression

In light of this, I am not resolving this ticket so that these action
items do not get overlooked.

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

Re: [Django] #26983: Boolean filter "field__isnull=False" not working with ForeignKey with to_field

2016-08-16 Thread Django

#26983: Boolean filter "field__isnull=False" not working with ForeignKey with
to_field
-+-
 Reporter:  weidwonder   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  queryset | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * has_patch:  1 => 0
 * severity:  Release blocker => Normal
 * stage:  Ready for checkin => Accepted


Comment:

 Could you send a pull request with those items? You can use "Refs #26983
 --" in the commit message.

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

Re: [Django] #26709: Add operation for creating database indexes and class based indexes

2016-08-16 Thread Django

#26709: Add operation for creating database indexes and class based indexes
-+
 Reporter:  akki |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  db-indexes   | 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:"a71724cd04e6b2b0c97f1cdbea2e528e65373be3" a71724cd]:
 {{{
 #!CommitTicketReference repository=""
 revision="a71724cd04e6b2b0c97f1cdbea2e528e65373be3"
 Refs #26709 -- Added index name to AddIndex.describe().
 }}}

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

Re: [Django] #27060: Take indexes into account in inspectdb command

2016-08-16 Thread Django

#27060: Take indexes into account in inspectdb command
-+-
 Reporter:  akki |Owner:  akki
 Type:  New feature  |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  db-indexes   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:  0 => 1


Comment:

 The complication is that `models.Index` might not match the type of the
 index. As noted on the PR, I'd think we'd at least want to add a comment
 in the output if the type of the introspected index doesn't match.

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

Re: [Django] #26709: Add operation for creating database indexes and class based indexes

2016-08-16 Thread Django

#26709: Add operation for creating database indexes and class based indexes
-+
 Reporter:  akki |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  db-indexes   | 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:"c969b17ad83e8efdd7f887b61ad75370395434ca" c969b17]:
 {{{
 #!CommitTicketReference repository=""
 revision="c969b17ad83e8efdd7f887b61ad75370395434ca"
 Refs #26709 -- Added type check for models.Index fields argument.
 }}}

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

Re: [Django] #16735: QuerySet.values() should be aliasable

2016-08-16 Thread Django

#16735: QuerySet.values() should be aliasable
-+-
 Reporter:  alex.latchford@… |Owner:  Ian-Foote
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  queryset, alias, | Triage Stage:  Accepted
  values |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 [https://github.com/django/django/pull/7088 PR] with some comments for
 improvement.

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

Re: [Django] #27069: Documentation for what's possible to import as _

2016-08-16 Thread Django

#27069: Documentation for what's possible to import as _
-+-
 Reporter:  lovmat   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  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 timgraham):

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

Re: [Django] #19222: Clarify that custom managers don't apply to intermediate joins

2016-08-16 Thread Django

#19222: Clarify that custom managers don't apply to intermediate joins
-+-
 Reporter:  andrewbadr   |Owner:
 Type:   |  yanikkoval
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  master
 Severity:  Normal   |   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 GitHub ):

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


Comment:

 In [changeset:"8fb53c50ce1c759c740960c9e1cef3cef39cabc5" 8fb53c50]:
 {{{
 #!CommitTicketReference repository=""
 revision="8fb53c50ce1c759c740960c9e1cef3cef39cabc5"
 Fixed #19222 -- Documented that default managers aren't used for related
 queries.
 }}}

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

Re: [Django] #19222: Clarify that custom managers don't apply to intermediate joins

2016-08-16 Thread Django

#19222: Clarify that custom managers don't apply to intermediate joins
-+-
 Reporter:  andrewbadr   |Owner:
 Type:   |  yanikkoval
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  master
 Severity:  Normal   |   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
-+-

Comment (by Tim Graham ):

 In [changeset:"8df2da36379cfce0efc7f2da96fc076ed221dc0a" 8df2da3]:
 {{{
 #!CommitTicketReference repository=""
 revision="8df2da36379cfce0efc7f2da96fc076ed221dc0a"
 [1.10.x] Fixed #19222 -- Documented that default managers aren't used for
 related queries.

 Backport of 8fb53c50ce1c759c740960c9e1cef3cef39cabc5 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/068.0b16e86fc4303e1d06e2cd999ce63908%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27070: Support for `Q` objects in `get_or_create` and `update_or_create`

2016-08-16 Thread Django

#27070: Support for `Q` objects in `get_or_create` and `update_or_create`
--+
 Reporter:  fcurella  |  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  Database layer (models, ORM)  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Since `Q` objects can be used to `.filter` queryset,I think it would make
 sense to leverage their functionality when looking up for objects in
 `get_or_create` or `update_or_create`.

 There currently isn't any way to use `Q` objects when checking for
 existence in  `get_or_create` and `update_or_create`. There are two main
 reasons for that:

 1. The signature of these methods prevents the usage of unnamed arguments
 2. When `OR`ing `Q` objects, if the lookup fails, and those fields are not
 specified in `defaults`, we have undefined values for the object that we
 need to create.

 We could address 1. by adding a keyword argument (let's call it `query`
 for now), so that the signature would be `get_or_create(defaults=None,
 query=None, **kwargs)`. It could then be used in this way:

 {{{
 obj, created = Person.objects.get_or_create(
 query=Q(first_name="George") | Q(first_name='Bruce'),
 defaults={"last_name": "Harrison"},
 )
 }}}

 Re 2., we have two options:

 2a. Leave the ambiguous fields undefined (but this would be inconsistent
 with the 'non-`query`' behavior).
 2b. Force the user to specify the field in `defaults` by raising some
 exception. Not happy about duplicating data in `query` and in `defaults`

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

Re: [Django] #26866: Lazy variant of string format

2016-08-16 Thread Django

#26866: Lazy variant of string format
--+
 Reporter:  lovmat|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Internationalization  |  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 timgraham):

 * needs_better_patch:  0 => 1


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

Re: [Django] #27070: Support for `Q` objects in `get_or_create` and `update_or_create`

2016-08-16 Thread Django

#27070: Support for `Q` objects in `get_or_create` and `update_or_create`
-+-
 Reporter:  fcurella |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 fcurella):

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


Comment:

 Proof of concept at https://github.com/django/django/pull/7101

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

Re: [Django] #27070: Support for `Q` objects in `get_or_create` and `update_or_create`

2016-08-16 Thread Django

#27070: Support for `Q` objects in `get_or_create` and `update_or_create`
-+-
 Reporter:  fcurella |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * stage:  Unreviewed => Someday/Maybe


Comment:

 I'm not immediately convinced the additional complexity is a good idea.
 Don't forget that adding a new keyword argument to `get_or_create()` could
 be backwards-incompatible for any models that have that field name. Could
 you write to the DevelopersMailingList to get some feedback?

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

Re: [Django] #27070: Support for `Q` objects in `get_or_create` and `update_or_create`

2016-08-16 Thread Django

#27070: Support for `Q` objects in `get_or_create` and `update_or_create`
-+-
 Reporter:  fcurella |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by jeffnuss):

 One thing I like about this proposal is that it makes the functionality of
 `get_or_create()` and `update_or_create()` feel more consistent with other
 query methods that can use `Q` objects like `get()`, `filter()` etc. We
 would probably want to use a similar argument like `defaults__exact` for
 the case of a model having `query` as a field name.

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

Re: [Django] #27070: Support for `Q` objects in `get_or_create` and `update_or_create`

2016-08-16 Thread Django

#27070: Support for `Q` objects in `get_or_create` and `update_or_create`
-+-
 Reporter:  fcurella |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by fcurella):

 Mailing list thread: https://groups.google.com/forum/#!topic/django-
 developers/e3sJ6OiHEd0

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

Re: [Django] #27069: Documentation for what's possible to import as _

2016-08-16 Thread Django

#27069: Documentation for what's possible to import as _
-+-
 Reporter:  lovmat   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  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
-+-

Comment (by claudep):

 Repeating what I wrote on the PR:
 The underlying issue is that xgettext consider `_` as a shortcut to a
 "simple" translation function. By simple, hear "one extractable string in
 the first parameter with no domain, context, plural, etc.". With a lexical
 analysis, it would not be possible to distinguish between different
 function signatures aliased to the same `_` shortcut.

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

Re: [Django] #27070: Support for `Q` objects in `get_or_create` and `update_or_create`

2016-08-16 Thread Django

#27070: Support for `Q` objects in `get_or_create` and `update_or_create`
-+-
 Reporter:  fcurella |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by charettes):

 > There currently isn't any way to use `Q` objects when checking for
 existence in `get_or_create` and `update_or_create`.

 Isn't `filter(Q(first_name='Bryan') |
 Q(first_name='Bruce')).get_or_create({'last_name': 'Harrison'})` working?

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

Re: [Django] #27070: Support for `Q` objects in `get_or_create` and `update_or_create`

2016-08-16 Thread Django

#27070: Support for `Q` objects in `get_or_create` and `update_or_create`
-+-
 Reporter:  fcurella |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by fcurella):

 @charettes

 O_O It didn't occur to me that it could be done that way. Seems to work
 exactly as I'd expect.

 Should I update my PR to simply add some tests of combining `.filter` with
 `.get_or_create` and maybe show an example in the docs?

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

[Django] #27071: Usability: We should be more precise when someone returns a string from a view function and not HttpResponse object

2016-08-16 Thread Django

#27071: Usability: We should be more precise when someone returns a string from 
a
view function and not HttpResponse object
--+-
 Reporter:  rushiagr  |  Owner:
 Type:  Cleanup/optimization  | Status:  new
Component:  Error reporting   |Version:  1.9
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  1
--+-
 The error currently is:

 AttributeError at 
 'str' object has no attribute 'get'

 The stacktrace printed is also equally inscrutable. I think we can be a
 little bit more thorough in checking return type ("if return type is a
 string, show our custom message), and avoid somebody
 googling/stackoverflowing for this issue instead of understanding the
 problem right away.

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

Re: [Django] #27070: Support for `Q` objects in `get_or_create` and `update_or_create`

2016-08-16 Thread Django

#27070: Support for `Q` objects in `get_or_create` and `update_or_create`
-+-
 Reporter:  fcurella |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by fcurella):

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


Comment:

 On a second thought, I dont think more work on the docs is necessary.
 Closing as 'invalid'

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

Re: [Django] #25187: Make request available in authentication backends

2016-08-16 Thread Django

#25187: Make request available in authentication backends
--+
 Reporter:  carljm|Owner:
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  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 timgraham):

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


Comment:

 [https://github.com/django/django/pull/6903 PR] with comments for
 improvement. Please uncheck "Patch needs improvement" after the pull
 request is updated.

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

Re: [Django] #27071: Usability: We should be more precise when someone returns a string from a view function and not HttpResponse object

2016-08-16 Thread Django

#27071: Usability: We should be more precise when someone returns a string from 
a
view function and not HttpResponse object
-+-
 Reporter:  rushiagr |Owner:
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Error reporting  |  Version:  1.9
 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:  1
-+-
Changes (by timgraham):

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


Comment:

 I'm not sure if imposing a type check performance penalty on every
 response is worth it.

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

Re: [Django] #25105: Migrating multiple CharFields to null=False breaks on PostgreSQL

2016-08-16 Thread Django

#25105: Migrating multiple CharFields to null=False breaks on PostgreSQL
+
 Reporter:  danielr |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.8
 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 rafadev):

 Seems to be happening also at least with PositiveIntegerField, even
 specifying a default when creating the migration.

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

Re: [Django] #26983: Boolean filter "field__isnull=False" not working with ForeignKey with to_field

2016-08-16 Thread Django

#26983: Boolean filter "field__isnull=False" not working with ForeignKey with
to_field
-+-
 Reporter:  weidwonder   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  queryset | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by lamby):

 Replying to [comment:13 timgraham]:
 > Could you send a pull request with those items? You can use "Refs #26983
 --" in the commit message.

 https://github.com/django/django/pull/7104

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

[Django] #27072: geodjango with migrations causes “duplicate collumn name error” with spatialight db

2016-08-16 Thread Django

#27072: geodjango with migrations causes “duplicate collumn name error” with
spatialight db
---+
Reporter: cancan101 | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized |Version: 1.10
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
---+
This is a repost of [http://stackoverflow.com/questions/14911503
/geodjango-with-south-causes-duplicate-collumn-name-error-with-
spatialight-db SO question]. The issue still seems to occur in Django 1.9
when using the built in migrations.

For example, when running tests I see (I have a column named
`capture_location` of type `PointField`):

{{{
Creating test database for alias 'default'...
AddGeometryColumn: "duplicate column name: capture_location"
... repeated many times
AddGeometryColumn: "duplicate column name: capture_location"
Destroying test database for alias 'default'...
}}}

(note that tests and server run without a problem)

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

Re: [Django] #17002: ManyToManyField through a model which extends some other model

2016-08-16 Thread Django

#17002: ManyToManyField through a model which extends some other model
-+-
 Reporter:  mitar|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 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 InvalidInterrupt):

 * cc: gm.lawr@… (added)
 * version:  master => 1.9


Comment:

 I recently encountered this bug on a project I am working on.

 I think that we may be able to fix the issue by changing
 {{{django.db.models.fields.related.ManyToManyField._get_path_info}}} to
 use some logic from {{{ django.db.models.sql.query.Query.names_to_path}}}
 (lines 1334-1349 in commit 698be78). To keep things maintainable, I'd like
 to split that logic out into a separate function (e.g.
 {{{get_path_to_parent_model(model, parent)}}}). Could someone with more
 familiarity with the codebase please suggest an appropriate place for this
 function to live?

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

[Django] #27073: Checks framework doesn't ignore overridden model managers

2016-08-16 Thread Django

#27073: Checks framework doesn't ignore overridden model managers
-+-
   Reporter:  timgraham  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  1.10
  layer (models, ORM)|
   Severity:  Release|   Keywords:
  blocker|
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 The following models from the Django test suite validate on Django 1.9.x
 but result in this error on Django 1.10:

 `CustomArticle.on_site: (sites.E001) CurrentSiteManager could not find a
 field named 'sites'.`

 {{{ #!python
 from django.contrib.sites.managers import CurrentSiteManager
 from django.contrib.sites.models import Site
 from django.db import models


 class AbstractArticle(models.Model):
 on_site = CurrentSiteManager()

 class Meta:
 abstract = True


 class CustomArticle(AbstractArticle):
 site_for_article = models.ForeignKey(Site, models.CASCADE)
 on_site = CurrentSiteManager('site_for_article')
 }}}

 Bisected to 3a47d42fa33012b2156bf04058d933df6b3082d2.
 `CustomArticle._meta.managers` shows both `CurrentSiteManager` instances
 and the one from the abstract model raises the error.

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

Re: [Django] #27072: geodjango with migrations causes “duplicate collumn name error” with spatialight db

2016-08-16 Thread Django

#27072: geodjango with migrations causes “duplicate collumn name error” with
spatialight db
---+--
 Reporter:  cancan101  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  GIS|  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 timgraham):

 * component:  Uncategorized => GIS
 * needs_better_patch:   => 0
 * type:  Uncategorized => Bug
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 I'm not sure the cause or resolution, but that error output also happens
 when running Django's test suite on SpatiaLite: `$ ./tests/runtests.py
 gis_tests.gis_migrations`.

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

Re: [Django] #17002: ManyToManyField through a model which extends some other model

2016-08-16 Thread Django

#17002: ManyToManyField through a model which extends some other model
-+-
 Reporter:  mitar|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 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 timgraham):

 Possibly `django/db/models/query_utils.py`, but it'll be easier to tell
 upon seeing the pull request so don't worry too much about it now.

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

Re: [Django] #17002: ManyToManyField through a model which extends some other model

2016-08-16 Thread Django

#17002: ManyToManyField through a model which extends some other model
-+-
 Reporter:  mitar|Owner:
 |  InvalidInterrupt
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 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 InvalidInterrupt):

 * status:  new => assigned
 * owner:  nobody => InvalidInterrupt


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

Re: [Django] #27065: Deferred fields not passed to inherited models' class.dict

2016-08-16 Thread Django

#27065: Deferred fields not passed to inherited models' __class__.__dict__
-+-
 Reporter:  jarekwg  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  defer only   | Triage Stage:
  inherited DeferredAttribute|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jarekwg):

 * keywords:  defer inherited => defer only inherited DeferredAttribute
 * status:  new => closed
 * resolution:   => invalid


Comment:

 Thanks, I've verified it's definitely commit
 7f51876f99851fdc3fef63aecdfbcffa199c26b9 that causes this change in
 behaviour.

 `DeferredAttribute` instances inherited from parent models can no longer
 be obtained through `instance.__class__.__dict__` because the class is
 
[https://github.com/django/django/commit/7f51876f99851fdc3fef63aecdfbcffa199c26b9
 #diff-1e7fc0d7d1b36358e371fab97bd1ddb1L236 no longer dynamically created],
 but rather has the `DeferredAttribute` instances
 
[https://github.com/django/django/commit/7f51876f99851fdc3fef63aecdfbcffa199c26b9
 #diff-bf776a3b8e5dbfac2432015825ef8afeR695 stapled on] with `setattr`.

 However, thanks to
 
[https://github.com/django/django/commit/7f51876f99851fdc3fef63aecdfbcffa199c26b9
 #diff-1e7fc0d7d1b36358e371fab97bd1ddb1R99 this change], a handle to the
 `DeferredAttribute` can be obtained by accessing the field directly from
 the instance's class, which looks considerably nicer and ''does'' pull
 through inherited fields.

 So
 `deffered_field = instance.__class__.__dict__.get(field_name)  # pre
 dj110`
 becomes
 `deferred_field = getattr(instance.__class__, field_name)  # dj110+`

 I guess it can't hurt mentioning this in the release notes, though at the
 same time I don't see particularly many projects that would need to handle
 the `DeferredAttributes` directly. You're in a better position to make
 that call. At the very least this ticket can serve as an answer to people
 who google this problem.

 Closing.

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

Re: [Django] #27073: Checks framework doesn't ignore overridden model managers

2016-08-16 Thread Django

#27073: Checks framework doesn't ignore overridden model managers
-+-
 Reporter:  timgraham|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Release blocker  |   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 loic):

 I'm not sure I get it. The `CustomArticle` doesn't seem to have a `site`
 field, so why shouldn't the warning be raised?

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

[Django] #27074: connection.is_usable() can raise AttributeError in natural uses

2016-08-16 Thread Django

#27074: connection.is_usable() can raise AttributeError in natural uses
--+
 Reporter:  cjerdonek |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.10
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 I know a [https://code.djangoproject.com/ticket/26282 similar issue] was
 closed relatively recently as won't fix, but I wanted to report a more
 obvious example of the same issue just to be sure.

 The following test case--

 {{{#!python
 from django.db import connection
 from django.test import TransactionTestCase

 class MyTest(TransactionTestCase):

 def test_connection_close(self):
 self.assertTrue(connection.is_usable())
 connection.close()
 self.assertFalse(connection.is_usable())
 }}}

 results in the following error (though if `TransactionTestCase` is
 replaced by `TestCase`, it would behave as expected)--

 {{{#!python
 Traceback (most recent call last):
   ...
   File ".../test_database.py", line 23, in test_connection_close
 self.assertTrue(connection.is_usable())
   File ".../site-packages/django/db/backends/postgresql/base.py", line
 229, in is_usable
 self.connection.cursor().execute("SELECT 1")
 AttributeError: 'NoneType' object has no attribute 'cursor'
 }}}

 Would there be any harm in handling the case of `self.connection` being
 `None` (e.g. using EAFP)?  It seems like this could even be done so the
 logic is only in the base 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/052.eb6c045e09b8d2d8ce8324b00382501f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

45 matches

Mail list logo