Re: [Django] #24082: Unique=True on TextField or CharField should not create an index

[Django]

#24082: Unique=True on TextField or CharField should not create an index
-+-
 Reporter:  djbug|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (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 djbug):

 I'll add one more thing to the above discussion:

 Based on my tests, the `text_pattern_ops` does not use index scan with `<
 <= > >=` operators. So the point about requiring 2 index is questionable.
 It's possible that I'm doing something wrong and would love to have
 someone verify this before coming to a conclusion.

 According to PG docs, the following operators are supported by
 `text_pattern_ops`:

 {{{

 "btree";"text_pattern_ops";"=(text,text)"
 "btree";"text_pattern_ops";"~<~(text,text)"
 "btree";"text_pattern_ops";"~<=~(text,text)"
 "btree";"text_pattern_ops";"~>=~(text,text)"
 "btree";"text_pattern_ops";"~>~(text,text)"

 }}}

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

Re: [Django] #24082: Unique=True on TextField or CharField should not create an index

[Django]

#24082: Unique=True on TextField or CharField should not create an index
-+-
 Reporter:  djbug|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (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 shaib):

 Replying to [comment:7 djbug]:
 >
 > A single `text_pattern_ops` index works for '''both''' `LIKE` & `=`
 queries. But it won't work for other operators like `< <= etc.`. But, I
 feel that, it would be an overkill to create 2 indexes by default. It
 should be left to the user to decide if they want double index or a single
 one with whichever operator class they want.

 I disagree; it is much easier to notice a superfluous index, or an
 explicitly-removed one (once `db_index=False` works), than one that is
 partly-missing (will work for anything except LIKE). If you're at the
 point where a superfluous index is hurting your performance, you're likely
 to be paying much closer attention to your database anyway; a missing
 index will hurt you much earlier.

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

Re: [Django] #24082: Unique=True on TextField or CharField should not create an index

[Django]

#24082: Unique=True on TextField or CharField should not create an index
-+-
 Reporter:  djbug|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (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 shaib):

 * cc: shaib (added)
 * stage:  Unreviewed => Accepted


Comment:

 First of all, +1 everything [comment:6 marfire] said.

 Replying to [comment:5 djbug]:
 > > Imposing uniqueness on text columns is almost always nonsense.
 >
 > For PostgreSQL, `CharField` maps to `varchar(n)` and `TextField` maps to
 `text`. According to the official docs, there's no performance difference
 between the two. Most DBA recommend `text` over `varchar(n)`
 ([http://stackoverflow.com/a/20334221/781695 Ref 1])
 ([http://blog.endpoint.com/2012/11/postgres-alter-column-problems-and.html
 Ref 2]).

 Well, I rephrase: s/text column/`TextField`/. `TextField`s are for big
 blobs of text, not identifiers.

 > That said, the above discussion about unique & index is true for
 `CharField` too as far as Django is concerned.
 >
 > > the issue here really is whether `unique=True` implies
 `db_index=True`. This holds for most field types, so I think most people
 would expect it to hold for text fields as well.
 >
 > Could you explain why should `unique=True` imply creation of an index
 explicitly ?

 It generally does not. An index is created explicitly only to support
 `LIKE` operations (as you noted, #12234).

 >
 > > You should get the behavior you expect, probably, with `unique=True,
 db_index=False`. If this indeed gives you what you want, I'd resolve this
 ticket by adding an admonition about this in the `TextField`
 documentation.
 >
 > I've tried your suggestion. For a `TextFIeld`, the following two
 generate the same constraint & index:
 > {{{
 > TextField( unique=True, db_index=False)
 > }}}
 > and
 > {{{
 > TextField( unique=True)
 > }}}
 >
 I'm accepting based on this (and documentation should be added as well).

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

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

Re: [Django] #24082: Unique=True on TextField or CharField should not create an index

[Django]

#24082: Unique=True on TextField or CharField should not create an index
-+-
 Reporter:  djbug|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (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
-+-

Comment (by djbug):

 Replying to [comment:6 marfire]:

 > However, this is the
 [https://docs.djangoproject.com/en/1.7/ref/models/fields/#unique currently
 documented behavior] ("Note that when `unique` is `True` you don’t need to
 specify `db_index`, because `unique` implies the creation of an index"),
 so there would be a backwards-compatibility problem in changing it.
 >
 > The fact that you can't prevent the creation of the extra index with an
 explicit `db_index=False` does feel like a bug, though, and something that
 could be fixed without a deprecation cycle.

 Agreed about backward compatibility & having `db_index=False` as a fix.

 > As for the suggestion to use a single `text_pattern_ops` unique index to
 serve double duty, the [http://www.postgresql.org/docs/9.3/static/indexes-
 opclass.html PostgreSQL documentation] makes it clear that that will not
 suffice to support all of Django's lookup types: "Note that you should
 also create an index with the default operator class if you want queries
 involving ordinary <, <=, >, or >= comparisons to use an index. Such
 queries cannot use the xxx_pattern_ops operator classes."

 A single `text_pattern_ops` index works for '''both''' `LIKE` & `=`
 queries. But it won't work for other operators like `< <= etc.`. But, I
 feel that, it would be an overkill to create 2 indexes by default. It
 should be left to the user to decide if they want double index or a single
 one with whichever operator class they want.

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

Re: [Django] #24082: Unique=True on TextField or CharField should not create an index

[Django]

#24082: Unique=True on TextField or CharField should not create an index
-+-
 Reporter:  djbug|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (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
-+-

Comment (by marfire):

 In my opinion it would be better to not have `unique=True` imply
 `db_index=True`. How the database enforces the constraint seems more like
 an implementation detail than something Django should guarantee.

 However, this is the
 [https://docs.djangoproject.com/en/1.7/ref/models/fields/#unique currently
 documented behavior] ("Note that when `unique` is `True` you don’t need to
 specify `db_index`, because `unique` implies the creation of an index"),
 so there would be a backwards-compatibility problem in changing it.

 The fact that you can't prevent the creation of the extra index with an
 explicit `db_index=False` does feel like a bug, though, and something that
 could be fixed without a deprecation cycle.

 As for the suggestion to use a single `text_pattern_ops` unique index to
 serve double duty, the [http://www.postgresql.org/docs/9.3/static/indexes-
 opclass.html PostgreSQL documentation] makes it clear that that will not
 suffice to support all of Django's lookup types: "Note that you should
 also create an index with the default operator class if you want queries
 involving ordinary <, <=, >, or >= comparisons to use an index. Such
 queries cannot use the xxx_pattern_ops operator classes."

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

[Django] #24088: Why is operator class used by default for PostgreSQL indexes on char & text field

[Django]

#24088: Why is operator class used by default for PostgreSQL indexes on char & 
text
field
---+
 Reporter:  djbug  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 [https://code.djangoproject.com/ticket/12234 Bug report 12234] modified
 the index for char & text fields in PostgreSQL to use operator class
 `varchar_pattern_ops` & `text_pattern_ops` respectively. This makes the
 index usable for `LIKE` queries.

 However there isn't any discussion on the additional cost associated with
 making this as the default option. It would have been a good optional
 feature. Consider the `username` column in `user` table. How often do we
 need to do `LIKE` queries on this.

 But if this needs to be maintained for backwards compatibility, there
 should be an option to get a vanilla index (without `*_pattern_op` class)
 if the column will be used for simple lookups of the type`WHERE name =
 'abc'`

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

Re: [Django] #24082: Unique=True on TextField or CharField should not create an index

[Django]

#24082: Unique=True on TextField or CharField should not create an index
-+-
 Reporter:  djbug|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (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
-+-

Comment (by djbug):

 > the issue here really is whether `unique=True` implies `db_index=True`.
 This holds for most field types, so I think most people would expect it to
 hold for text fields as well.

 Could you explain why should `unique=True` imply creation of an index
 explicitly ? AFAIK, this would duplicate the index in PostgreSQL  (& a few
 other databases according to the old bug reports mentioned above). If we
 remove this explicit index, there's no drop in performance because
 internally the db maintains an index for a unique constraint.

 > You should get the behavior you expect, probably, with `unique=True,
 db_index=False`. If this indeed gives you what you want, I'd resolve this
 ticket by adding an admonition about this in the `TextField`
 documentation.

 I've tried your suggestion. For a `TextFIeld`, the following two generate
 the same constraint & index:
 {{{
 TextField( unique=True, db_index=False)
 }}}
 and
 {{{
 TextField( unique=True)
 }}}

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

Re: [Django] #12663: Formalize, refactor, and document Model._meta

[Django]

#12663: Formalize, refactor, and document Model._meta
-+-
 Reporter:  MadeR|Owner:  pirosb3
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  1.8-alpha| Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"fb48eb05816b1ac87d58696cdfe48be18c901f16"]:
 {{{
 #!CommitTicketReference repository=""
 revision="fb48eb05816b1ac87d58696cdfe48be18c901f16"
 Fixed #12663 -- Formalized the Model._meta API for retrieving fields.

 Thanks to Russell Keith-Magee for mentoring this Google Summer of
 Code 2014 project and everyone else who helped with the patch!
 }}}

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

Re: [Django] #12663: Formalize, refactor, and document Model._meta

[Django]

#12663: Formalize, refactor, and document Model._meta
-+-
 Reporter:  MadeR|Owner:  pirosb3
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  1.8-alpha| 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):

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

Re: [Django] #23891: Revise deprecation / removal timeline for IPAddressField

[Django]

#23891: Revise deprecation / removal timeline for IPAddressField
-+-
 Reporter:  MarkusH  |Owner:  timgraham
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Tim Graham ):

 In [changeset:"749d23251bbd6564341405e6f8c1da129b8307e7"]:
 {{{
 #!CommitTicketReference repository=""
 revision="749d23251bbd6564341405e6f8c1da129b8307e7"
 Removed warning handling that should have been removed in refs #23891.
 }}}

--
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.1f76c78306c1d33f233874226dc6706e%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)

[Django]

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

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


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

Re: [Django] #22603: Reorganize code in django.db.backends

[Django]

#22603: Reorganize code in django.db.backends
-+-
 Reporter:  aaugustin|Owner:  gchp
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  1.8-alpha| 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):

 There are still a couple large patches that touch these classes that may
 make it into 1.8 (in particular,
 [https://github.com/django/django/pull/3669 PR 3669]), so let's hold off a
 bit longer on this -- I'm thinking after the "feature freeze" on Monday,
 but before we cut the branch and issue an alpha release.

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

Re: [Django] #20003: URLValidator does not accept urls with usernames or passwords in them

[Django]

#20003: URLValidator does not accept urls with usernames or passwords in them
-+-
 Reporter:  marshall@…   |Owner:  Tim
 |  Graham 
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:  1.5
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  URLValidator | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"2e65d56156b622e2393dee1af66e9c799a51924f"]:
 {{{
 #!CommitTicketReference repository=""
 revision="2e65d56156b622e2393dee1af66e9c799a51924f"
 Fixed #20003 -- Improved and extended URLValidator

 This adds support for authentication data (`user:password`) in URLs,
 IPv6 addresses, and unicode domains.

 The test suite has been improved by adding test URLs from
 http://mathiasbynens.be/demo/url-regex (with a few adjustments,
 like allowing local and reserved IPs).

 The previous URL validation regex failed this test suite on 13
 occasions, the validator was updated based on
 https://gist.github.com/dperini/729294.
 }}}

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

Re: [Django] #19820: Make loaddata error messages less cryptic

[Django]

#19820: Make loaddata error messages less cryptic
--+
 Reporter:  bigfudge  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Serialization)  |  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 timgraham):

 * needs_better_patch:  1 => 0


Comment:

 Don't forget to uncheck "Patch needs improvement" so the ticket appears in
 the review queue.

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

Re: [Django] #19820: Make loaddata error messages less cryptic

[Django]

#19820: Make loaddata error messages less cryptic
--+
 Reporter:  bigfudge  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Serialization)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Naddiseo):

 Rebased, and responded to question.

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

Re: [Django] #24082: Unique=True on TextField or CharField should not create an index

[Django]

#24082: Unique=True on TextField or CharField should not create an index
-+-
 Reporter:  djbug|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (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
-+-

Comment (by shaib):

 Imposing uniqueness on text columns is almost always nonsense (and doesn't
 work at all on Oracle). If it weren't for backwards compatibility, I'd
 suggest we flag it as an error.

 That said, the issue here really is whether `unique=True` implies
 `db_index=True`. This holds for most field types, so I think most people
 would expect it to hold for text fields as well.

 You should get the behavior you expect, probably, with `unique=True,
 db_index=False`. If this indeed gives you what you want, I'd resolve this
 ticket by adding an admonition about this in the `TextField`
 documentation.

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

Re: [Django] #24087: django.contrib.forms.UserCreationForm inheritence won't work

[Django]

#24087: django.contrib.forms.UserCreationForm inheritence won't work
-+-
 Reporter:  sh4r3m4n |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.auth |  Version:  1.7
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
  forms,auth,users,custom|  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => duplicate
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Duplicate of #19353

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

[Django] #24087: django.contrib.forms.UserCreationForm inheritence won't work

[Django]

#24087: django.contrib.forms.UserCreationForm inheritence won't work
--+-
 Reporter:  sh4r3m4n  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  contrib.auth  |Version:  1.7
 Severity:  Normal|   Keywords:  forms,auth,users,custom
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+-
 If I create a custom User model based on AbstractUser, i should also
 create a custom user creation form, inheriting from
 django.contrib.forms.UserCreationForm and defining the custom model I
 created in the Meta subclass. This won't work properly because
 UserCreationForm always use auth.User model when cleaning the username
 instead of the one defined in Meta.
 This should be patched changing lines 101 and 102 of
 contrib/auth/forms.py, from this:
 101 User._default_manager.get(username=username)
 102 except User.DoesNotExist:
 To this
 101 self.Meta.model._default_manager.get(username=username)
 102 except self.Meta.model.DoesNotExist:

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

Re: [Django] #24086: No pre_migrate signal is emitted if rolling back the migration history

[Django]

#24086: No pre_migrate signal is emitted if rolling back the migration history
+--
 Reporter:  andrewhayes1979 |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.7
 Severity:  Normal  |   Resolution:
 Keywords:  pre_migrate signal  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by andrewhayes1979):

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


Comment:

 Addendum, the actual behaviour is slightly more confusing than first
 reported, try this:

 myapp + MyModel, generate initial migration 0001, migrate:
  - pre_migrate and post_migrate fired

 add field to MyModel, makemigrations to generate 0002, migrate:
  - pre_migrate and post_migrate fired

 migrate back to 0001:
  - only post_migrate fired ''(as reported above)''

 migrate forwards to 0002:
  - only post_migrate fired ''(expected this to work the same as case #2,
 forwards migration from 0001 -> 0002)''

 add another field to MyModel, makemigrations to generate 003, migrate
  - pre_migrate, post_migrate are fired (as expected)

 ...the current behaviour is slightly confusing...

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

[Django] #24086: No pre_migrate signal is emitted if rolling back the migration history

[Django]

#24086: No pre_migrate signal is emitted if rolling back the migration history
-+
 Reporter:  andrewhayes1979  |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Migrations   |Version:  1.7
 Severity:  Normal   |   Keywords:  pre_migrate signal
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 Use case:

 Suppose I have an app "myapp" with a model "MyModel", run makemigrations
 to generate 0001 and then migrate:
  - I'll get both the pre_migrate and post_migrate signals fired when
 running the migration

 If I then add a field to MyModel, run makemigrations to generate 0002 and
 then migrate:
  - I'll also get both the pre_migrate and post_migrate signals fired.

 (this was addressed in this ticket:
 https://code.djangoproject.com/ticket/23975)

 If I now run "python manage.py migrate myapp 0001" to rollback the 0002
 migration, I'll only get a post_migrate signal emitted, '''no
 pre_migrate'''.

 The sync_apps() function that the pre_migrate signal emit code lives in is
 never called in this use case.


 Desired behaviour:
  - '''all''' calls to migrate should generate pre_migrate and post_migrate
 signals to bookend the start/end of database schema modifications

 ...the documentation for the pre_migrate signal currently states that it
 is fired only when installing an app, however the fix for
 https://code.djangoproject.com/ticket/23975 means this is no longer
 accurate.

 ...simply firing the 2 events anytime a database schema migration occurs
 (forwards or backwards) would be simpler and easier to understand, IMO


 Also, as an aside, it would be nice if richer information were provided in
 the post_migrate signal in terms of a list of model-classes that were
 modified for e.g.  I'm currently relying on database introspection in
 pre_migrate and post_migrate signal-handlers to watch for changes in
 model-schemas...since the migration-functionality knows what it has/hasn't
 run, it'd be nice if this information were shared out in the post_migrate
 signal perhaps?

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

[Django] #24085: @requires_login decorator redirects to a locale specific URL when using i18n_patterns

[Django]

#24085: @requires_login decorator redirects to a locale specific URL when using
i18n_patterns
-+-
 Reporter:  thedrow  |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:   |Version:  master
  Internationalization   |   Keywords:  authentication i18n
 Severity:  Normal   |  login_required
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 When an anonymous user is hitting a view decorated with @login_required
 that is routed using i18n_patterns he will be first redirected to the
 default locale URL e.g. /en-us/ and after that he will be redirected to
 the login view. The next query parameter will be /en-us/ which will
 override whatever language is in LANGUAGE_SESSION_KEY and set the site's
 language to en-us when the user logs in.

 The solution is very simple. We need to strip the locale part of the URI
 when setting the next query parameter.


 {{{
 def strip_language_from_path(path):
 """
 Strips the language-code if there is a valid language-code
 found in the `path`.
 """
 regex_match = language_code_prefix_re.match(path)
 if not regex_match:
 return None
 path = regex_match.group(2)
 return path


 def user_passes_test(test_func, login_url=None,
 redirect_field_name=REDIRECT_FIELD_NAME):
 """
 Decorator for views that checks that the user passes the given test,
 redirecting to the log-in page if necessary. The test should be a
 callable
 that takes the user object and returns True if the user passes.
 """

 def decorator(view_func):
 @wraps(view_func, assigned=available_attrs(view_func))
 def _wrapped_view(request, *args, **kwargs):
 if test_func(request.user):
 return view_func(request, *args, **kwargs)
 path = request.build_absolute_uri()
 # urlparse chokes on lazy objects in Python 3, force to str
 resolved_login_url = force_str(
 resolve_url(login_url or settings.LOGIN_URL))
 # If the login url is the same scheme and net location then
 just
 # use the path as the "next" url.
 login_scheme, login_netloc = urlparse(resolved_login_url)[:2]
 current_scheme, current_netloc = urlparse(path)[:2]
 if ((not login_scheme or login_scheme == current_scheme) and
 (not login_netloc or login_netloc == current_netloc)):
 path = request.get_full_path()

 path = strip_language_from_path(path)

 from django.contrib.auth.views import redirect_to_login

 return redirect_to_login(
 path, resolved_login_url, redirect_field_name)

 return _wrapped_view

 return decorator
 }}}

 I can issue a PR with this change if desired.
 If not, is there another way to fix this 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/050.dbc7783f1faeb54e3f01661e0b841e24%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23712: BaseForm._html_output() uses inconsistent formatting for normal row

[Django]

#23712: BaseForm._html_output() uses inconsistent formatting for normal row
+
 Reporter:  alflanagan  |Owner:  raully7
 Type:  Bug |   Status:  assigned
Component:  Forms   |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+

Comment (by raully7):

 Replying to [comment:9 timgraham]:
 > Did you see the existing [https://github.com/django/django/pull/3529
 pull request] and the questions on it?

 Sorry, I thought it's unsigned and wasn't aware of wadevries' pull
 request.

 And even worse, I just submitted another
 [https://github.com/django/django/pull/3847 pull request]...

 Sorry for bother your guys, I should be more careful.

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

Re: [Django] #24083: Docs incorrectly refer to form's is_bound() method

[Django]

#24083: Docs incorrectly refer to form's is_bound() method
---+
 Reporter:  ajenhl |Owner:  claudep
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+

Comment (by Claude Paroz ):

 In [changeset:"5e18f6f724dda3f6462c92f825b31b2e423f4e7c"]:
 {{{
 #!CommitTicketReference repository=""
 revision="5e18f6f724dda3f6462c92f825b31b2e423f4e7c"
 [1.7.x] Fixed #24083 -- Corrected is_bound nature in forms topic docs

 Thanks ajenhl Trac user for the report.
 Backport of e0080cf57 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/064.5178ef4848535b128f7291fc81a96349%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24083: Docs incorrectly refer to form's is_bound() method

[Django]

#24083: Docs incorrectly refer to form's is_bound() method
---+
 Reporter:  ajenhl |Owner:  claudep
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:  fixed
 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 Claude Paroz ):

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


Comment:

 In [changeset:"e0080cf577166e160987c74e2d8324ddbbee3b6d"]:
 {{{
 #!CommitTicketReference repository=""
 revision="e0080cf577166e160987c74e2d8324ddbbee3b6d"
 Fixed #24083 -- Corrected is_bound nature in forms topic docs

 Thanks ajenhl Trac user 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/064.6e999d0bc944b572fa5e5661098795e6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.