date:20150220

Re: [Django] #24376: UUIDField doesn't take a verbose_name positional arg

2015-02-20 Thread Django

#24376: UUIDField doesn't take a verbose_name positional arg
-+-
 Reporter:  yoyoma   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8alpha1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  1.8-beta | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by yoyoma):

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

Re: [Django] #24376: UUIDField doesn't take a verbose_name positional arg

2015-02-20 Thread Django

#24376: UUIDField doesn't take a verbose_name positional arg
-+-
 Reporter:  yoyoma   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8alpha1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  1.8-beta | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by yoyoma):

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

Re: [Django] #24377: UUIDField as primary key breaks inline admins

2015-02-20 Thread Django

#24377: UUIDField as primary key breaks inline admins
-+-
 Reporter:  yoyoma   |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by yoyoma):

 @timgraham - I tried to debug this some and ended up down a deep rabbit
 hole.

 I ended up '''possibly''' finding another bug. With stable/1.8.x (without
 your changes), given the example models, if you create a {{{Child}}}
 instance for an existing {{{Parent}}}, set {{{max_num = 1}}} on the inline
 (just to avoid empty forms, since you only created 1 child), then visit
 the change view for that {{{Parent}}} and save it, all should be well, but
 all is not well. The global {{{Please correct the errors below.}}} appears
 at the top, but there are no errors. Removing the inline admin fixes that
 issue, and checking "delete" on the inline instance is not met with this
 issue, so the issue is certainly pertaining validation of the inline form
 or instance.

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

Re: [Django] #23718: TEST_MIRROR setting doesn't work as expected (and has no tests)

2015-02-20 Thread Django

#23718: TEST_MIRROR setting doesn't work as expected (and has no tests)
---+
 Reporter:  coagulant  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.7
 Severity:  Normal |   Resolution:
 Keywords:  replica testing| Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by harrykao):

 Is it possible to have the mirrors share a connection? Using
 `TransactionTestCase` has the additional disadvantage of preventing
 multiprocessed test runs, which works fine when each test runs in a
 transaction.

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

Re: [Django] #24341: Subclasses of django.contrib.postgres.forms.ranges.BaseRangeField should have more specific error messages

2015-02-20 Thread Django

#24341: Subclasses of django.contrib.postgres.forms.ranges.BaseRangeField should
have more specific error messages
-+-
 Reporter:  void |Owner:  foresmac
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.postgres |  Version:  1.8alpha1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  i18n, postgres   | Triage Stage:  Ready for
  1.8-beta   |  checkin
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:"3207fcd0a0b90e677b1bb5cf662dee21c659adab"]:
 {{{
 #!CommitTicketReference repository=""
 revision="3207fcd0a0b90e677b1bb5cf662dee21c659adab"
 [1.8.x] Fixed #24341 -- Added specific error messages to RangeField
 subclasses

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

Re: [Django] #24341: Subclasses of django.contrib.postgres.forms.ranges.BaseRangeField should have more specific error messages

2015-02-20 Thread Django

#24341: Subclasses of django.contrib.postgres.forms.ranges.BaseRangeField should
have more specific error messages
-+-
 Reporter:  void |Owner:  foresmac
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.postgres |  Version:  1.8alpha1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  i18n, postgres   | Triage Stage:  Ready for
  1.8-beta   |  checkin
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:"1d1d5d1c315e0e58f02a7f2a07b56ed20b09c087"]:
 {{{
 #!CommitTicketReference repository=""
 revision="1d1d5d1c315e0e58f02a7f2a07b56ed20b09c087"
 Fixed #24341 -- Added specific error messages to RangeField subclasses
 }}}

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

Re: [Django] #24377: UUIDField as primary key breaks inline admins

2015-02-20 Thread Django

#24377: UUIDField as primary key breaks inline admins
-+-
 Reporter:  yoyoma   |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  master
 Severity:  Release blocker  |   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


Comment:

 Unfortunately, there is a failing test for a case involving model
 inheritance and editable primary keys.

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

Re: [Django] #24380: First locmem email sent in tests is absurdly slow.

2015-02-20 Thread Django

#24380: First locmem email sent in tests is absurdly slow.
-+-
 Reporter:  fletom   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Mail)  |  Version:  1.7
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  email fqdn   | Triage Stage:
  performance tests  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by fletom):

 I also agree that your suggestion to use a mock monkey patch is a better
 idea that changing the `locmem` backend just for tests. 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/064.04210c0575155e8696bc445ca4f578eb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24341: Subclasses of django.contrib.postgres.forms.ranges.BaseRangeField should have more specific error messages

2015-02-20 Thread Django

#24341: Subclasses of django.contrib.postgres.forms.ranges.BaseRangeField should
have more specific error messages
-+-
 Reporter:  void |Owner:  foresmac
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  contrib.postgres |  Version:  1.8alpha1
 Severity:  Normal   |   Resolution:
 Keywords:  i18n, postgres   | Triage Stage:  Ready for
  1.8-beta   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|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/062.7623879b968ce9424c839c969984cf41%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24377: UUIDField as primary key breaks inline admins

2015-02-20 Thread Django

#24377: UUIDField as primary key breaks inline admins
-+-
 Reporter:  yoyoma   |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  master
 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
-+-
Changes (by timgraham):

 * has_patch:  0 => 1


Comment:

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

Re: [Django] #24377: UUIDField as primary key breaks inline admins

2015-02-20 Thread Django

#24377: UUIDField as primary key breaks inline admins
-+-
 Reporter:  yoyoma   |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  master
 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
-+-
Changes (by timgraham):

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


Comment:

 There appear to be a couple problems here:

 Since the use of `UUIDField` as a primary key requires
 `default=uuid.uuid4`, initializing an object sets its primary key in
 
[https://github.com/django/django/blob/bed504d70bede3431a213203c13a33905d6dbf77/django/db/models/base.py#L426-L427
 Model.__init__()]:
 {{{
 >>> p = Parent()
 >>> p.pk
 UUID('cde58b1c-4a5a-471a-901c-6e43847f0a0e')
 }}}
 That value is then used as the initial value for
 
[https://github.com/django/django/blob/bed504d70bede3431a213203c13a33905d6dbf77/django/forms/models.py#L931
 InlineForeignKeyField] on the inlines. It needs to be ignored since it
 will be regenerated on subsequent requests since the field isn't editable
 and there's no way to preserve state across requests.

 Secondly, the primary key on the inline uses an auto-generated value from
 the `default` of the `Child.uuid` field during the save request, but it's
 empty on the request for the initial form. This discrepancy causes
 `Form.has_changed()` to return `True` which triggers "required" validation
 on other fields, even on otherwise empty inlines.

 I have a patch that seems to fix these issues and am working on adding
 tests.

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

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

Re: [Django] #24380: First locmem email sent in tests is absurdly slow.

2015-02-20 Thread Django

#24380: First locmem email sent in tests is absurdly slow.
-+-
 Reporter:  fletom   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Mail)  |  Version:  1.7
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  email fqdn   | Triage Stage:
  performance tests  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by carljm):

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


Comment:

 I agree, I think the locmem backend should handle messages as similarly as
 possible to the real backend. If `socket.getfqdn()` is a problem on your
 particular machine, it shouldn't be hard to mock it for your tests.

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

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

Re: [Django] #24380: First locmem email sent in tests is absurdly slow.

2015-02-20 Thread Django

#24380: First locmem email sent in tests is absurdly slow.
-+-
 Reporter:  fletom   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Mail)  |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  email fqdn   | Triage Stage:
  performance tests  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by claudep):

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


Comment:

 We might argue that the real bug is your machine's `socket.getfqdn()`
 slowness. I'm not sure it's a good idea to strip the `locmem` backend (see
 #18861 about the reason this was introduced).
 I think the solution would be for you to mock `socket.getfqdn()` in your
 tests.

 Keeping it open for getting another opinion.

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

Re: [Django] #24375: Add ability to mark migration as "part of initial" in Migration (was: Add ability to mark migration as fake in Migration)

2015-02-20 Thread Django

#24375: Add ability to mark migration as "part of initial" in Migration
-+
 Reporter:  haeric   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  fake migrations  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by carljm):

 * needs_better_patch:   => 0
 * stage:  Unreviewed => Accepted
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 I think there is a reasonable feature request here, except that it should
 not be an "always-fake" attribute. This doesn't really make conceptual
 sense, since the need for faking is never inherent in a migration, it
 always depends on the state of the database the migration is run against.
 In your particular situation, it may be true that you will only ever run
 these migrations against existing databases (I guess you don't use
 Django's test runner?), but that's an unusual scenario (and I doubt it's
 even true in your case -- you'll never again ever spin up a new
 environment of this app?)

 The version of this that makes sense to me is a migration attribute that
 says "I should be considered a part of the initial migration, for purposes
 of auto-faking when Django detects that the tables for this app already
 exist."

 I would suggest that this attribute be named `initial`, and always be set
 on the actual initial migration too. Then there is no longer any implicit
 special-casing of the first migration; the auto-fake behavior would just
 auto-fake until it reaches a migration without `initial = True`.

 Making this change would allow us to get rid of the special case mentioned
 in the documentation, where sometimes if two initial migrations are
 created you have to manually fake the second one.

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

Re: [Django] #24328: The new Options._get_fields() method needs to be cleaned up

2015-02-20 Thread Django

#24328: The new Options._get_fields() method needs to be cleaned up
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8alpha1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  1.8-beta | 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 Tim Graham ):

 In [changeset:"6f03a4ca91ed22b2ea42d5159a1ed00f347cf9aa"]:
 {{{
 #!CommitTicketReference repository=""
 revision="6f03a4ca91ed22b2ea42d5159a1ed00f347cf9aa"
 [1.8.x] Fixed #24328 -- cleaned up Options._get_fields() implementation

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

[Django] #24380: First locmem email sent in tests is absurdly slow.

2015-02-20 Thread Django

#24380: First locmem email sent in tests is absurdly slow.
-+-
Reporter: fletom | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Core (Mail) |Version: 1.7
Severity: Normal | Keywords: email fqdn performance
| tests
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 1| UI/UX: 0
-+-
Some of my application's tests send email. When running tests, Django sets
`EMAIL_BACKEND` to be `django.core.mail.backends.locmem.EmailBackend`.
This backend's `send_messages` calls `message.message()` on each email in
order to do header validation. However, this has the side effect of
generating a `Message-ID` email header, which calls `make_msgid()`, which
ends up calling `socket.getfqdn()`. On my machine, `socket.getfqdn()`
takes over 5 seconds to return. The `socket.getfqdn()` is cached,
fortunately, so the 5 second delay only happens once.

Five seconds may seem small but it is really significant when you're
rapidly alternating between writing code and running tests, and it's
totally unnecessary to set a `Message-ID` header on emails in
`django.core.mail.backends.locmem`. Right now my large test suite runs in
600 ms if I comment out that one pesky call that turns it into 5800 ms. So
while this isn't a bug, I think fixing it would be a really nice quality-
of-life change.

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

Re: [Django] #24328: The new Options._get_fields() method needs to be cleaned up

2015-02-20 Thread Django

#24328: The new Options._get_fields() method needs to be cleaned up
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8alpha1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  1.8-beta | 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:

 In [changeset:"bad5f262bf4a17f157808ec1aa225ba9c94c1eee"]:
 {{{
 #!CommitTicketReference repository=""
 revision="bad5f262bf4a17f157808ec1aa225ba9c94c1eee"
 Fixed #24328 -- cleaned up Options._get_fields() implementation
 }}}

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

Re: [Django] #24080: Sqlite segmentation fault regression when running tests (since 1.7.2)

2015-02-20 Thread Django

#24080: Sqlite segmentation fault regression when running tests (since 1.7.2)
---+
 Reporter:  stevejalim |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:  invalid
 Keywords:  sqlite | 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):

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


Comment:

 As Django only officially supports the latest micro release, I think we
 can close this.

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

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

Re: [Django] #24080: Sqlite segmentation fault regression when running tests (since 1.7.2)

2015-02-20 Thread Django

#24080: Sqlite segmentation fault regression when running tests (since 1.7.2)
---+
 Reporter:  stevejalim |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  sqlite | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by foresmac):

 I can confirm that updating from default 2.7.6 on OS X 10.10 to 2.7.9 gets
 rid of the error.

 I did notice that Homebrew also installed an updated version of sqlite3;
 so I can't say for 100% sure if it was just the Python update or the
 updated sqlite3 that Homebrew binds to Python 2.7.9.

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

Re: [Django] #24351: RunPython/RunSQL operations in contrib migrations and multi-db routers.

2015-02-20 Thread Django

#24351: RunPython/RunSQL operations in contrib migrations and multi-db routers.
-+-
 Reporter:  loic |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Migrations   |  Version:  1.8alpha1
 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 loic):

 * severity:  Release blocker => Normal


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

Re: [Django] #24366: Improve migration dependency graph speed

2015-02-20 Thread Django

#24366: Improve migration dependency graph speed
--+
 Reporter:  MarkusH   |Owner:  knbk
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Migrations|  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 knbk):

 The caching does wonders when performing searches in super/subtrees of
 previously performed searches, but the algorithm itself is a real
 downgrade from the previous one.

 I'm also looking into partially ordered sets to see if that is any faster,
 I'll let you know if anything comes out of 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/065.bd9cc175d07c4d1f398a272446c3daba%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24346: AuthRouter docs lead to AttributeError: 'NoneType' object has no attribute '_meta' with 0002_remove_content_type_name

2015-02-20 Thread Django

#24346: AuthRouter docs lead to AttributeError: 'NoneType' object has no
attribute
'_meta' with 0002_remove_content_type_name
-+-
Reporter: pzrq |Owner: nobody
Type: Bug | Status: closed
Component: Documentation| Version: 1.8alpha1
Severity: Release blocker | 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 Loic Bistuer ):

In [changeset:"3a6c37fce452a3bbf185b5e58dd3e7c89b456b19"]:
{{{
#!CommitTicketReference repository=""
revision="3a6c37fce452a3bbf185b5e58dd3e7c89b456b19"
[1.8.x] Fixed #24351, #24346 -- Changed the signature of allow_migrate().

The new signature enables better support for routing RunPython and
RunSQL operations, especially w.r.t. reusable and third-party apps.

This commit also takes advantage of the deprecation cycle for the old
signature to remove the backward incompatibility introduced in #22583;
RunPython and RunSQL won't call allow_migrate() when when the router
has the old signature.

Thanks Aymeric Augustin and Tim Graham for helping shape up the patch.

Refs 22583.

Conflicts:
django/db/utils.py

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

Re: [Django] #23932: Document how to set a unique value for new fields using migrations

2015-02-20 Thread Django

#23932: Document how to set a unique value for new fields using migrations
--+
 Reporter:  michaeljohnbarr   |Owner:  akulakov
 Type:  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:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Loic Bistuer ):

 In [changeset:"564487601e34b9962ad16bc7e4e62c8b68928c84"]:
 {{{
 #!CommitTicketReference repository=""
 revision="564487601e34b9962ad16bc7e4e62c8b68928c84"
 [1.8.x] Fixed #23932 -- Added how-to on migrating unique fields.

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

Re: [Django] #24351: RunPython/RunSQL operations in contrib migrations and multi-db routers.

2015-02-20 Thread Django

#24351: RunPython/RunSQL operations in contrib migrations and multi-db routers.
-+-
 Reporter:  loic |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Migrations   |  Version:  1.8alpha1
 Severity:  Release blocker  |   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 Loic Bistuer ):

 In [changeset:"3a6c37fce452a3bbf185b5e58dd3e7c89b456b19"]:
 {{{
 #!CommitTicketReference repository=""
 revision="3a6c37fce452a3bbf185b5e58dd3e7c89b456b19"
 [1.8.x] Fixed #24351, #24346 -- Changed the signature of allow_migrate().

 The new signature enables better support for routing RunPython and
 RunSQL operations, especially w.r.t. reusable and third-party apps.

 This commit also takes advantage of the deprecation cycle for the old
 signature to remove the backward incompatibility introduced in #22583;
 RunPython and RunSQL won't call allow_migrate() when when the router
 has the old signature.

 Thanks Aymeric Augustin and Tim Graham for helping shape up the patch.

 Refs 22583.

 Conflicts:
 django/db/utils.py

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

Re: [Django] #24351: RunPython/RunSQL operations in contrib migrations and multi-db routers.

2015-02-20 Thread Django

#24351: RunPython/RunSQL operations in contrib migrations and multi-db routers.
-+-
 Reporter:  loic |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Migrations   |  Version:  1.8alpha1
 Severity:  Release blocker  |   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 Loic Bistuer ):

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


Comment:

 In [changeset:"bed504d70bede3431a213203c13a33905d6dbf77"]:
 {{{
 #!CommitTicketReference repository=""
 revision="bed504d70bede3431a213203c13a33905d6dbf77"
 Fixed #24351, #24346 -- Changed the signature of allow_migrate().

 The new signature enables better support for routing RunPython and
 RunSQL operations, especially w.r.t. reusable and third-party apps.

 This commit also takes advantage of the deprecation cycle for the old
 signature to remove the backward incompatibility introduced in #22583;
 RunPython and RunSQL won't call allow_migrate() when when the router
 has the old signature.

 Thanks Aymeric Augustin and Tim Graham for helping shape up the patch.

 Refs 22583.
 }}}

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

Re: [Django] #24346: AuthRouter docs lead to AttributeError: 'NoneType' object has no attribute '_meta' with 0002_remove_content_type_name

2015-02-20 Thread Django

* resolution: duplicate => fixed

Comment:

In [changeset:"bed504d70bede3431a213203c13a33905d6dbf77"]:
{{{
#!CommitTicketReference repository=""
revision="bed504d70bede3431a213203c13a33905d6dbf77"
Fixed #24351, #24346 -- Changed the signature of allow_migrate().

The new signature enables better support for routing RunPython and
RunSQL operations, especially w.r.t. reusable and third-party apps.

Thanks Aymeric Augustin and Tim Graham for helping shape up the patch.

Refs 22583.
}}}

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

Re: [Django] #24366: Improve migration dependency graph speed

2015-02-20 Thread Django

Comment (by knbk):

Sure. There are still a few kinks to work out (e.g. the
`CircularDependencyError` message throws another error), but I believe the
generated graphs satisfies the requirements. There are still 5 test
failures.

The biggest issue here is that `migrations.test_graph.GraphTests.test_dfs`
fails because it reaches the maximum recursion depth. This is expected and
a result of switching (back) to a recursive design. I haven't looked into
memory usage yet, I'm pretty sure memory usage is increased significantly,
but I don't know how much.

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

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

Re: [Django] #24367: ORA-00918 (column ambiguously defined) when using a combination of slicing, distinct, and order_by

2015-02-20 Thread Django

#24367: ORA-00918 (column ambiguously defined) when using a combination of 
slicing,
distinct, and order_by
-+-
 Reporter:  skoot|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  ORA-00918 oracle | Triage Stage:
  queryset   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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

Re: [Django] #24376: UUIDField doesn't take a verbose_name positional arg

2015-02-20 Thread Django

#24376: UUIDField doesn't take a verbose_name positional arg
-+-
 Reporter:  yoyoma   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8alpha1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  1.8-beta | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by timgraham):

 * keywords:   => 1.8-beta


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

Re: [Django] #24367: ORA-00918 (column ambiguously defined) when using a combination of slicing, distinct, and order_by

2015-02-20 Thread Django

#24367: ORA-00918 (column ambiguously defined) when using a combination of 
slicing,
distinct, and order_by
-+-
 Reporter:  skoot|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ORA-00918 oracle | Triage Stage:
  queryset   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by skoot):

 I just checked and it's fixed in django 1.8.

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

Re: [Django] #24379: Document that user management tools don't work with remote authentication (was: Mention disabling local users explicitly)

2015-02-20 Thread Django

#24379: Document that user management tools don't work with remote 
authentication
--+
 Reporter:  mkesper   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.7
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by timgraham):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * easy:  0 => 1
 * needs_docs:   => 0
 * type:  Uncategorized => Cleanup/optimization
 * 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/065.f25d59b466d3fdac64abc389a74b6901%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24378: Clarify what should be reported here

2015-02-20 Thread Django

#24378: Clarify what should be reported here
---+--
 Reporter:  mkesper|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Documentation  |  Version:  1.7
 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):

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


Comment:

 How about: "Report bugs and suggest features in Django itself (or its
 documentation) using this ticket tracker."

 Ironically, this is an issue on code.djangoproject.com and so should have
 been reported on GitHub, but let's just resolve it quickly and then close
 this. ;-)

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

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

Re: [Django] #24351: RunPython/RunSQL operations in contrib migrations and multi-db routers.

2015-02-20 Thread Django

#24351: RunPython/RunSQL operations in contrib migrations and multi-db routers.
-+-
 Reporter:  loic |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Migrations   |  Version:  1.8alpha1
 Severity:  Release blocker  |   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/062.e5a59323a7d9d20dc3b7aa6953d5a420%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24328: The new Options._get_fields() method needs to be cleaned up

2015-02-20 Thread Django

#24328: The new Options._get_fields() method needs to be cleaned up
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8alpha1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  1.8-beta | 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


Comment:

 It seems like this patch is ready, pending some minor cleanup of comments
 which I can do later today if needed.

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

Re: [Django] #24366: Improve migration dependency graph speed

2015-02-20 Thread Django

#24366: Improve migration dependency graph speed
--+
 Reporter:  MarkusH   |Owner:  knbk
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Migrations|  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 MarkusH):

 That sounds crazy. Want to open 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/065.e76f02f32f402edb32bc2ef12ac8aaeb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #24379: Mention disabling local users explicitly

2015-02-20 Thread Django

#24379: Mention disabling local users explicitly
---+
 Reporter:  mkesper|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  1.7
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 If you configure according to https://docs.djangoproject.com/en/1.7/howto
 /auth-remote-user/#authentication-using-remote-user you disable all local
 users.
 This should be mentioned explicitly.
 You will still be able to use commands like eg manage.py createsuperuser
 but they won't give any effect.

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

[Django] #24378: Clarify what should be reported here

2015-02-20 Thread Django

#24378: Clarify what should be reported here
---+
 Reporter:  mkesper|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  1.7
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The readme1st reads: "Please create an issue on GitHub for issues with our
 web site (www.djangoproject.com) or with Trac (code.djangoproject.com)."

 Clarify what '''should''' be reported here.

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

Re: [Django] #24371: Recommend that new projects start with PostgreSQL

2015-02-20 Thread Django

#24371: Recommend that new projects start with PostgreSQL
--+
 Reporter:  carljm|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.7
 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):

 Oh, I completely misread comment:2, sorry. Was probably not completely
 awake. And yes, it's also my experience that user management in Postgres
 might be a little more tricky than on MySQL.

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

Re: [Django] #24377: UUIDField as primary key breaks inline admins

2015-02-20 Thread Django

#24377: UUIDField as primary key breaks inline admins
-+
 Reporter:  yoyoma   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  master
 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
-+
Changes (by mjtamlyn):

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

Re: [Django] #24373: RegexValidator In ArrayField Not Running

2015-02-20 Thread Django

#24373: RegexValidator In ArrayField Not Running
-+-
 Reporter:  DavidMuller  |  Owner:  Marc Tamlyn
 |  
 Type:  Uncategorized| Status:  closed
Component:  contrib.postgres |Version:  1.8alpha1
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ArrayField   |   Triage Stage:  Unreviewed
  RegexValidator |
Has patch:  0|  Easy pickings:  0
UI/UX:  0|
-+-

Comment (by Marc Tamlyn ):

 In [changeset:"b6ef67d752cab200028c39c31c602dd6696b69ce"]:
 {{{
 #!CommitTicketReference repository=""
 revision="b6ef67d752cab200028c39c31c602dd6696b69ce"
 [1.8.x] Fixed #24373 -- Added run_validators to ArrayField.

 Thanks to DavidMuller for the report.

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

Re: [Django] #24373: RegexValidator In ArrayField Not Running

2015-02-20 Thread Django

#24373: RegexValidator In ArrayField Not Running
-+-
 Reporter:  DavidMuller  |  Owner:  Marc Tamlyn
 |  
 Type:  Uncategorized| Status:  closed
Component:  contrib.postgres |Version:  1.8alpha1
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ArrayField   |   Triage Stage:  Unreviewed
  RegexValidator |
Has patch:  0|  Easy pickings:  0
UI/UX:  0|
-+-
Changes (by Marc Tamlyn ):

 * owner:   => Marc Tamlyn 
 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"c490e410af086fa89f40d515505bba02a08168f3"]:
 {{{
 #!CommitTicketReference repository=""
 revision="c490e410af086fa89f40d515505bba02a08168f3"
 Fixed #24373 -- Added run_validators to ArrayField.

 Thanks to DavidMuller for the report.
 }}}

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

Re: [Django] #24343: UUID foreign key accessor returns inconsistent type

2015-02-20 Thread Django

#24343: UUID foreign key accessor returns inconsistent type
-+-
 Reporter:  timgraham|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.8alpha1
  (models, ORM)  |
 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
-+-

Comment (by Marc Tamlyn ):

 In [changeset:"c54d73ae01cd787315ba030da17e266c49f386b3"]:
 {{{
 #!CommitTicketReference repository=""
 revision="c54d73ae01cd787315ba030da17e266c49f386b3"
 [1.8.x] Fixed #24343 -- Ensure db converters are used for foreign keys.

 Joint effort between myself, Josh, Anssi and Shai.

 Conflicts:
 django/db/models/query.py
 tests/model_fields/models.py

 Backport of 4755f8fc25331c739a6f932cc8aba0cc9e62e352 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.80457bb345c08bca8d88bcf43370fabb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24343: UUID foreign key accessor returns inconsistent type

2015-02-20 Thread Django

#24343: UUID foreign key accessor returns inconsistent type
-+-
 Reporter:  timgraham|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.8alpha1
  (models, ORM)  |
 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 Marc Tamlyn ):

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


Comment:

 In [changeset:"4755f8fc25331c739a6f932cc8aba0cc9e62e352"]:
 {{{
 #!CommitTicketReference repository=""
 revision="4755f8fc25331c739a6f932cc8aba0cc9e62e352"
 Fixed #24343 -- Ensure db converters are used for foreign keys.

 Joint effort between myself, Josh, Anssi and Shai.
 }}}

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

Re: [Django] #24347: parameter 'widget' of BoundField.as_widget is ignored

2015-02-20 Thread Django

#24347: parameter 'widget' of BoundField.as_widget is ignored
-+-
 Reporter:  srkunze  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.8alpha1
 Severity:  Normal   |   Resolution:
 Keywords:  BoundField,  | Triage Stage:
  as_widget  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Description changed by srkunze:

Old description:

> 'as_widget' has the parameter 'widget' which renders the field. However,
> this parameter is not used all the time during the 'as_widget' call.
>
> The method 'data', which is (indirectly via 'value') called by
> 'as_widget' ALWAYS used the default widget of the field which leads to
> issues like formatting etc.
>
> We recognized this issue when using 'show_hidden_initial=True' and
> widgets for datetime objects.
>
> The problem can also be observed when using BoundField.as_hidden as it
> uses 'as_widget' as well.
>
> cf.
> as_widget:
> https://github.com/django/django/blob/master/django/forms/forms.py#L526
> data:
> https://github.com/django/django/blob/master/django/forms/forms.py#L569
> as_hidden:
> https://github.com/django/django/blob/master/django/forms/forms.py#L562
>
> Versions: 1.4, 1.5, 1.6, 1.7, 1.8, master

New description:

 'as_widget' has the parameter 'widget' which renders the field. However,
 this parameter is not used all the time during the 'as_widget' call.

 The method 'data', which is (indirectly via 'value') called by
 'as_widget', ALWAYS uses the default widget of the field which leads to
 issues like formatting etc.

 We recognized this issue when using 'show_hidden_initial=True' and widgets
 for datetime objects.

 The problem can also be observed when using BoundField.as_hidden as it
 uses 'as_widget' as well.

 cf.
 as_widget:
 https://github.com/django/django/blob/master/django/forms/forms.py#L526
 data:
 https://github.com/django/django/blob/master/django/forms/forms.py#L569
 as_hidden:
 https://github.com/django/django/blob/master/django/forms/forms.py#L562

 Versions: 1.4, 1.5, 1.6, 1.7, 1.8, 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/065.8ee3413c11eeac5a8dabfd310d60f500%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24371: Recommend that new projects start with PostgreSQL

2015-02-20 Thread Django

#24371: Recommend that new projects start with PostgreSQL
--+
 Reporter:  carljm|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.7
 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 aaugustin):

 Usually you manage MySQL users and tables from within the MySQL shell with
 special commands. I remember having to use shell commands instead as a
 problem for me about 5 years ago.

 The problem is compounded by:

 - the need to run commands as the `postgres` user (sudo su postgres)
 - the learning curve of pg_hba.conf, which is why I'm suggesting to use a
 superuser for local development

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

Re: [Django] #22298: Rename Media to Static

2015-02-20 Thread Django

#22298: Rename Media to Static
--+
 Reporter:  aaugustin |Owner:
 Type:  Cleanup/optimization  |   Status:  new
Component:  Forms |  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 sthzg):

 I also think that it is valuable to have the functionality in Django
 Admin. Like mentioned above, it allows to add enhancements to certain
 views easily while not having to override the admin templates. I think
 that there are many small projects that are maintained through Django
 Admin and being able to drop in some Javascript for certain views is
 essential, at least for me. I would miss this functionality if it was gone
 completely (instead of keeping it or deprecating it in favor of something
 more elaborate).

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

Re: [Django] #24377: UUIDField as primary key breaks inline admins

2015-02-20 Thread Django

#24377: UUIDField as primary key breaks inline admins
-+--
 Reporter:  yoyoma   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Release blocker  |   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 claudep):

 Could be a duplicate of #15665…

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

Re: [Django] #24376: UUIDField doesn't take a verbose_name positional arg

2015-02-20 Thread Django

#24376: UUIDField doesn't take a verbose_name positional arg
-+-
 Reporter:  yoyoma   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8alpha1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by claudep):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * type:  Uncategorized => Cleanup/optimization
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 Sure!

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

Re: [Django] #24372: Remove django.template.base.TokenParser?

2015-02-20 Thread Django

#24372: Remove django.template.base.TokenParser?
--+
 Reporter:  prestontimmons|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Template system   |  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):

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


Comment:

 If the tests are happy, so do I :-)

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

Re: [Django] #24371: Recommend that new projects start with PostgreSQL

2015-02-20 Thread Django

#24371: Recommend that new projects start with PostgreSQL
--+
 Reporter:  carljm|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.7
 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):

 Aymeric, I don't see why your previous comment is specific to MySQL. For
 any database, isn't a requirement that the database user used for running
 tests needs the "CREATE DATABASE" permission (SQLite aside)?

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

50 matches

Mail list logo