date:20150417

Re: [Django] #24656: Query Expressions page do not always show imports

2015-04-17 Thread Django

Comment (by jarshwah):

Fully agree that examples should have imports shown and that the import
paths should be clear at either the top of the file or inline for each
type.

Regarding your linking to the source comment, are you referencing the
[source] annotations in some of the documentation? If so, those links
should only ever be supplementary for the curious, and absolutely not
required for complete understanding. I would disagree with the suggestion
that they should be removed if that's the suggestion being made. It's
entirely possible that I've misunderstood though.

If you have any other suggestions for improving the expressions
documentation, please raise them. Writing documentation for your own code
can be tricky, because you're not sure what is too little or too much
information sometimes.

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

Re: [Django] #24497: Truncation of microseconds in DateTimeField leads to lookup trouble

2015-04-17 Thread Django

#24497: Truncation of microseconds in DateTimeField leads to lookup trouble
--+
 Reporter:  riklaunim |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Forms |  Version:  1.7
 Severity:  Normal|   Resolution:
 Keywords:  microseconds  | 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/4467 PR]

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

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

Re: [Django] #24654: infinite loop caused by ordering, triggered by relational primary key construct

2015-04-17 Thread Django

#24654: infinite loop caused by ordering, triggered by relational primary key
construct
-+-
 Reporter:  elmbeech |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 With all three `Meta.ordering` attributes removed (not sure if you wanted
 that or just the bottom two):
 {{{
 SELECT "infiniteloop_infinitloop"."infinity",
 "infiniteloop_infinitloop"."loop_id" FROM "infiniteloop_infinitloop" INNER
 JOIN "infiniteloop_theloop" ON ( "infiniteloop_infinitloop"."loop_id" =
 "infiniteloop_theloop"."loop" ) ORDER BY
 "infiniteloop_theloop"."target_organism_id" ASC,
 "infiniteloop_theloop"."host_organism_id" ASC
 }}}
 With just the bottom two removed:
 {{{
 SELECT "infiniteloop_infinitloop"."infinity",
 "infiniteloop_infinitloop"."loop_id" FROM "infiniteloop_infinitloop" INNER
 JOIN "infiniteloop_theloop" ON ( "infiniteloop_infinitloop"."loop_id" =
 "infiniteloop_theloop"."loop" ) INNER JOIN "infiniteloop_organism" ON (
 "infiniteloop_theloop"."target_organism_id" =
 "infiniteloop_organism"."organism" ) INNER JOIN "infiniteloop_organism" T4
 ON ( "infiniteloop_theloop"."host_organism_id" = T4."organism" ) ORDER BY
 "infiniteloop_organism"."organism" ASC, T4."organism" ASC
 }}}

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

Re: [Django] #24349: Limit URL domain name labels to 63 characters

2015-04-17 Thread Django

#24349: Limit URL domain name labels to 63 characters
-+-
 Reporter:  atmb4u   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  gTLD, email  | Triage Stage:  Ready for
  validation |  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:"24003295088ec24d823f66bd5c8b917478b24c5d" 24003295]:
 {{{
 #!CommitTicketReference repository=""
 revision="24003295088ec24d823f66bd5c8b917478b24c5d"
 Fixed #24349 -- Limited domain name labels to 63 characters in
 EmailValidator
 }}}

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

Re: [Django] #24653: Database introspection doesn't work when using MySQL OPTIONS['read_default_file'] (was: Migrations: Removing a field with foreign key constraint fails)

2015-04-17 Thread Django

#24653: Database introspection doesn't work when using MySQL
OPTIONS['read_default_file']
-+-
 Reporter:  karolyi  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  foreign key  | Triage Stage:  Accepted
  constraint mysql   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * component:  Migrations => Database layer (models, ORM)
 * stage:  Unreviewed => Accepted


Comment:

 Oops, I forgot the remove the `DATABASES['NAME']` key when I tested with
 `read_default_file`.  I can indeed reproduce it now.

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

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

Re: [Django] #24653: Migrations: Removing a field with foreign key constraint fails

2015-04-17 Thread Django

#24653: Migrations: Removing a field with foreign key constraint fails
-+-
 Reporter:  karolyi  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  foreign key  | Triage Stage:
  constraint mysql   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by karolyi):

 I think I found the culprit. Just as I expected, using
 `read_default_file`, for which you don't need to define the database name
 in the settings, ends up in `self.connection.settings_dict['NAME']` being
 an empty string in
 
[https://github.com/django/django/blob/bd0883d5cc51ba0c4e106c9e20bfc94b296d6320/django/db/backends/mysql/introspection.py#L162
 db/backends/mysql/introspection.py:162]

 In my case, as I shown in my example with manually looking up/removing the
 foreign key, you'll need to use

 {{{
 cursor.execute('SELECT DATABASE()')
 }}}

 To fetch the DB name.

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

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

Re: [Django] #24653: Migrations: Removing a field with foreign key constraint fails

2015-04-17 Thread Django

#24653: Migrations: Removing a field with foreign key constraint fails
-+-
 Reporter:  karolyi  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  foreign key  | Triage Stage:
  constraint mysql   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by karolyi):

 Replying to [comment:6 timgraham]:
 > What is the value if `fk_names` when you see the crash?

 I just did a debug, it's an empty list (`[]`).

 Did you setup the mysql client as I did, with the `read_default_file`
 option?

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

Re: [Django] #24653: Migrations: Removing a field with foreign key constraint fails

2015-04-17 Thread Django

Comment (by timgraham):

Still no luck for me on reproducing. There's some

[https://github.com/django/django/blob/bd0883d5cc51ba0c4e106c9e20bfc94b296d6320/django/db/backends/base/schema.py#L437-L439
logic in the SchemaEditor] to remove indexes before the column is dropped.
What is the value if `fk_names` when you see the crash? In my case it's
something like
`['polls_choice_poll_id_776991a85051577d_fk_polls_poll_id']`. The index in
your error message is quite a bit shorter which seems suspicious.

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

Re: [Django] #24653: Migrations: Removing a field with foreign key constraint fails

2015-04-17 Thread Django

#24653: Migrations: Removing a field with foreign key constraint fails
-+-
 Reporter:  karolyi  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  foreign key  | Triage Stage:
  constraint mysql   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by karolyi):

 * Attachment "variables.txt" added.

 Mysql variables

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

Re: [Django] #24653: Migrations: Removing a field with foreign key constraint fails

2015-04-17 Thread Django

#24653: Migrations: Removing a field with foreign key constraint fails
-+-
 Reporter:  karolyi  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  foreign key  | Triage Stage:
  constraint mysql   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by karolyi):

 * Attachment "traceback.txt" added.

 error traceback

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

Re: [Django] #24653: Migrations: Removing a field with foreign key constraint fails

2015-04-17 Thread Django

#24653: Migrations: Removing a field with foreign key constraint fails
-+-
 Reporter:  karolyi  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  foreign key  | Triage Stage:
  constraint mysql   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by karolyi):

 * Attachment "0001_initial.py" added.

 initial migration

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

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

Re: [Django] #24653: Migrations: Removing a field with foreign key constraint fails

2015-04-17 Thread Django

#24653: Migrations: Removing a field with foreign key constraint fails
-+-
 Reporter:  karolyi  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  foreign key  | Triage Stage:
  constraint mysql   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by karolyi):

 * Attachment "0002_remove_choice_question.py" added.

 Removing the question foreign key

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

Re: [Django] #24653: Migrations: Removing a field with foreign key constraint fails

2015-04-17 Thread Django

#24653: Migrations: Removing a field with foreign key constraint fails
-+-
 Reporter:  karolyi  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  foreign key  | Triage Stage:
  constraint mysql   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by karolyi):

 Replying to [comment:4 timgraham]:
 > Which MySQL version and storage engine are you using? I tried to
 reproduce using the tutorial by removing the `question =
 models.ForeignKey(Question)` field. Can you reproduce using that method?
 Tested with MySQL 5.6.19 and both InnoDB and MyISAM storage engines;
 Django master and stable/1.8.x branches.

 I use MySQL 5.6.24, with Django 1.8, Python 3.4.3, and mysqlclient 1.3.6.

 I managed to narrow down the problem to a specific mysql setting. As it
 seems, when you use a mysql configuration in `settings.py` like

 {{{
 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.mysql',
 'OPTIONS': {
 'read_default_file': os.path.join(
 BASE_DIR,
 'mysql.conf'
 )
 }
 }
 }
 }}}

 and the content of mysql.conf being
 {{{
 [client]
 database = django_test
 user = root
 # password = PASSWORD
 default-character-set = utf8
 }}}
 , using mysql locally.

 This way you'll be able to reproduce the problem w/ using your example
 from the tutorial. In that case, you should get something like

 {{{
 django.db.utils.OperationalError: (1553, "Cannot drop index
 'polls_choice_7aa0f6ee': needed in a foreign key constraint")
 }}}

 Generated migration files, as well as the error traceback, attached.

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

Re: [Django] #24397: Speed up model rendering with apps.ready = False

2015-04-17 Thread Django

#24397: Speed up model rendering with apps.ready = False
-+-
 Reporter:  knbk |Owner:  knbk
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by knbk):

 * needs_better_patch:  1 => 0
 * stage:  Accepted => Ready for checkin


Comment:

 I'm not too sure what the error message should be changed to, so I'll
 leave it as is.

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

Re: [Django] #24656: Query Expressions page do not always show imports

2015-04-17 Thread Django

Comment (by pydanny):

Tim explains the issue better than I can. ;)

Yes, a note at the top of the page saying all expressions are available
from django.db.models would be perfect.

For reference, I'm of the somewhat well-known firm belief that all code
examples in documentation should either include the imports of framework
objects, or mention their import path prominently in the documentation.
Also, no offense, but I also think linking to the source code is rather
unfair to beginners, being just a step above telling them to 'read the
source'.

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

Re: [Django] #24573: "Unknown column" exception after removing field in migration.

2015-04-17 Thread Django

#24573: "Unknown column" exception after removing field in migration.
-+
 Reporter:  tttomekkk|Owner:  MarkusH
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.8
 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 MarkusH):

 * needs_docs:  1 => 0
 * needs_tests:  1 => 0


Comment:

 I finally added a test case. Ready for review.

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

Re: [Django] #24595: alter field type on MySQL "forgets" nullability (and more)

2015-04-17 Thread Django

#24595: alter field type on MySQL "forgets" nullability (and more)
-+
 Reporter:  simonpercivall   |Owner:
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.7
 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 claudep):

 * has_patch:  1 => 0
 * stage:  Ready for checkin => 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/072.35d1d26ab7b5ca38e05573dcba9fa621%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24595: alter field type on MySQL "forgets" nullability (and more)

2015-04-17 Thread Django

#24595: alter field type on MySQL "forgets" nullability (and more)
-+-
 Reporter:  simonpercivall   |Owner:
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.7
 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 claudep):

 * owner:  claudep =>
 * status:  assigned => new


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

Re: [Django] #24595: alter field type on MySQL "forgets" nullability (and more)

2015-04-17 Thread Django

#24595: alter field type on MySQL "forgets" nullability (and more)
-+-
 Reporter:  simonpercivall   |Owner:  claudep
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.7
 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 claudep):

 * owner:  Claude Paroz  => claudep
 * status:  new => assigned


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

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

Re: [Django] #24595: alter field type on MySQL "forgets" nullability (and more)

2015-04-17 Thread Django

#24595: alter field type on MySQL "forgets" nullability (and more)
-+-
 Reporter:  simonpercivall   |Owner:  Claude
 |  Paroz 
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.7
 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 claudep):

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


Comment:

 The failures on Oracle shown in Jenkins tend to show that Oracle may also
 be affected by this bug. I'll hand this over to a more knowledgeable
 person, though.

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

Re: [Django] #24660: In gCBVs, decouple get_context_data() and get_template_names() from get() and post()

2015-04-17 Thread Django

#24660: In gCBVs, decouple get_context_data() and get_template_names() from 
get()
and post()
-+-
 Reporter:  akulakov |Owner:  akulakov
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Generic views|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by akulakov):

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


Old description:

> Currently there are a few gCBVs where get_context_data and
> get_template_names methods are closely coupled with get() and post()
> methods: if self.object or self.object_list are not created in get() or
> post(), get_context_data and get_template_names will fail.
>
> The reason for that is probably because respective attrs were meant to be
> set always in get()/post() to make them available for use in all
> subsequent methods.
>
> However, this creates unnecessary need to override methods in order to
> set these attrs when customizing or mixing gCBVs.
>
> It would be tempting to simply init object=None and object_list=None at
> class level but unfortunately object=None has the special meaning in
> CreateView - "object is to be created on form submission and so should
> not be added to context when form is rendered".
>
> I propose the following behaviour:
>
>  * get_context_data() should not depend on get() and set() and should get
> the object or list from respective methods
>
>  * get_template_names() should not error out if the object or object_list
> are unset.
>
> Here are some examples of customized gCBVs where this change leads to a
> simpler design:
>
> {{{
> # ContextCreateView is implementation of CreateView according to
> # https://github.com/django/django/pull/4512
>
> # note that no methods need to be overridden
> class BooksCreateView(ContextCreateView, ListView):
> model = Book
> paginate_by   = 10
> fields= ["name", "author"]
> success_url   = reverse_lazy("list-books-create")
> template_name = "books.html"
>
> class AuthorDetail2(DetailView, ContextFormView):
> model = Author
> form_class = AuthorInterestForm
> template_name = "author2.html"
>
> def form_valid(self, form):
> # Here, we would have some logic based on user's form inputs
> return redirect('author2', pk=self.get_object().pk)
> }}}

New description:

 Currently there are a few gCBVs where get_context_data and
 get_template_names methods are closely coupled with get() and post()
 methods: if self.object or self.object_list are not created in get() or
 post(), get_context_data and get_template_names will fail.

 The reason for that is probably because respective attrs were meant to be
 set always in get()/post() to make them available for use in all
 subsequent methods.

 However, this creates unnecessary need to override methods in order to set
 these attrs when customizing or mixing gCBVs.

 It would be tempting to simply init object=None and object_list=None at
 class level but unfortunately object=None has the special meaning in
 CreateView - "object is to be created on form submission and so should not
 be added to context when form is rendered".

 I propose the following behaviour:

  * get_context_data() should not depend on get() and set() and should get
 the object or list from respective methods

  * get_template_names() should not error out if the object or object_list
 are unset.

 Here are some examples of customized gCBVs where this change leads to a
 simpler design:

 {{{
 # ContextCreateView is implementation of CreateView according to
 # https://github.com/django/django/pull/4512

 # note that no methods need to be overridden
 class BooksCreateView(ContextCreateView, ListView):
 model = Book
 paginate_by   = 10
 fields= ["name", "author"]
 success_url   = reverse_lazy("list-books-create")
 template_name = "books.html"

 class AuthorDetail2(DetailView, ContextFormView):
 model = Author
 form_class = AuthorInterestForm
 template_name = "author2.html"

 def form_valid(self, form):
 # Here, we would have some logic based on user's form inputs
 return redirect('author2', pk=self.get_object().pk)
 }}}


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

--

--
Ticket URL: 
Django 
The Web framework for

[Django] #24660: In gCBVs, decouple get_context_data() and get_template_names() from get() and post()

2015-04-17 Thread Django

#24660: In gCBVs, decouple get_context_data() and get_template_names() from 
get()
and post()
--+--
 Reporter:  akulakov  |  Owner:  akulakov
 Type:  Cleanup/optimization  | Status:  new
Component:  Generic views |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+--
 Currently there are a few gCBVs where get_context_data and
 get_template_names methods are closely coupled with get() and post()
 methods: if self.object or self.object_list are not created in get() or
 post(), get_context_data and get_template_names will fail.

 The reason for that is probably because respective attrs were meant to be
 set always in get()/post() to make them available for use in all
 subsequent methods.

 However, this creates unnecessary need to override methods in order to set
 these attrs when customizing or mixing gCBVs.

 It would be tempting to simply init object=None and object_list=None at
 class level but unfortunately object=None has the special meaning in
 CreateView - "object is to be created on form submission and so should not
 be added to context when form is rendered".

 I propose the following behaviour:

  * get_context_data() should not depend on get() and set() and should get
 the object or list from respective methods

  * get_template_names() should not error out if the object or object_list
 are unset.

 Here are some examples of customized gCBVs where this change leads to a
 simpler design:

 {{{
 # ContextCreateView is implementation of CreateView according to
 # https://github.com/django/django/pull/4512

 # note that no methods need to be overridden
 class BooksCreateView(ContextCreateView, ListView):
 model = Book
 paginate_by   = 10
 fields= ["name", "author"]
 success_url   = reverse_lazy("list-books-create")
 template_name = "books.html"

 class AuthorDetail2(DetailView, ContextFormView):
 model = Author
 form_class = AuthorInterestForm
 template_name = "author2.html"

 def form_valid(self, form):
 # Here, we would have some logic based on user's form inputs
 return redirect('author2', pk=self.get_object().pk)
 }}}

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

Re: [Django] #24654: infinite loop caused by ordering, triggered by relational primary key construct

2015-04-17 Thread Django

#24654: infinite loop caused by ordering, triggered by relational primary key
construct
-+-
 Reporter:  elmbeech |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (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 charettes):

 I think the models are valid.

 Tim, if you still have the code used to reproduce around could try
 removing both `ordering` clause and printing the following query
 `InfinitLoop.objects.order_by('loop__target_organism',
 'loop__host_organism')`.

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

Re: [Django] #24349: Limit URL domain name labels to 63 characters

2015-04-17 Thread Django

#24349: Limit URL domain name labels to 63 characters
-+-
 Reporter:  atmb4u   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  gTLD, email  | Triage Stage:  Ready for
  validation |  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/064.5e7bb0d977038e1f9d5ef60d8a06d142%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24655: Admin RelatedFieldWidgetWrapper does not build static url correctly

2015-04-17 Thread Django

#24655: Admin RelatedFieldWidgetWrapper does not build static url correctly
-+-
 Reporter:  ewhitmire|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.8
 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:  1|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"901de5fbcedf1ad04d3e47a610aa5ed1cc657cb9" 901de5f]:
 {{{
 #!CommitTicketReference repository=""
 revision="901de5fbcedf1ad04d3e47a610aa5ed1cc657cb9"
 [1.8.x] Fixed #24655 -- Fixed JavaScript path of contrib.admin's related
 field widget
 }}}

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

Re: [Django] #24655: Admin RelatedFieldWidgetWrapper does not build static url correctly

2015-04-17 Thread Django

#24655: Admin RelatedFieldWidgetWrapper does not build static url correctly
-+-
 Reporter:  ewhitmire|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  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


Comment:

 Will add release notes and commit.

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

Re: [Django] #24656: Query Expressions page do not always show imports

2015-04-17 Thread Django

#24656: Query Expressions page do not always show imports
--+
 Reporter:  pydanny   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.8
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by timgraham):

 * type:  Uncategorized => Cleanup/optimization
 * easy:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 Examples not showing imports seems to be the complaint as far as I can
 tell. We could add a note at the top about expressions being available
 from `django.db.models`.

 See also #15396.

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

Re: [Django] #15396: full path to modules in documentation inconsistently referenced

2015-04-17 Thread Django

#15396: full path to modules in documentation inconsistently referenced
---+
 Reporter:  slinkp@…   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  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 timgraham):

 One option to display the full module path is something like this:
 {{{
 #!diff
 diff --git a/docs/ref/models/expressions.txt
 b/docs/ref/models/expressions.txt
 index f74c4f2..d0b4a14 100644
 --- a/docs/ref/models/expressions.txt
 +++ b/docs/ref/models/expressions.txt
 @@ -360,7 +360,8 @@ output value.
  ``ExpressionWrapper()`` expressions
  ---

 -.. class:: ExpressionWrapper(expression, output_field)
 +.. class:: django.db.models.ExpressionWrapper(expression, output_field)
 +:module:

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

Re: [Django] #24653: Migrations: Removing a field with foreign key constraint fails

2015-04-17 Thread Django

#24653: Migrations: Removing a field with foreign key constraint fails
-+-
 Reporter:  karolyi  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  foreign key  | Triage Stage:
  constraint mysql   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 Which MySQL version and storage engine are you using? I tried to reproduce
 using the tutorial by removing the `question =
 models.ForeignKey(Question)` field. Can you reproduce using that method?
 Tested with MySQL 5.6.19 and both InnoDB and MyISAM storage engines;
 Django master and stable/1.8.x branches.

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

Re: [Django] #24654: infinite loop caused by ordering, triggered by relational primary key construct

2015-04-17 Thread Django

#24654: infinite loop caused by ordering, triggered by relational primary key
construct
-+-
 Reporter:  elmbeech |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (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 timgraham):

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


Comment:

 The models didn't appear obviously invalid to me (but if they are, maybe
 we could add a system check about it). I could reproduce the traceback
 with the code above.

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

Re: [Django] #23879: We should use test-skipping, not conditional discovery in runtests.py

2015-04-17 Thread Django

#23879: We should use test-skipping, not conditional discovery in runtests.py
--+
 Reporter:  carljm|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * needs_better_patch:  0 => 1


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

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

Re: [Django] #23879: We should use test-skipping, not conditional discovery in runtests.py

2015-04-17 Thread Django

#23879: We should use test-skipping, not conditional discovery in runtests.py
--+
 Reporter:  carljm|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by claudep):

 * needs_better_patch:  1 => 0


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

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

Re: [Django] #24509: Allow Expressions when saving new models

2015-04-17 Thread Django

#24509: Allow Expressions when saving new models
-+-
 Reporter:  AlexHill |Owner:
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (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 adamchainz):

 * cc: me@… (added)


Comment:

 I also have a use-case for this - I'm trying to implement MariaDB Dynamic
 Columns which require calling a function to create (
 https://mariadb.com/kb/en/mariadb/dynamic-columns/#column_create ).

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

Re: [Django] #24652: SimpleTestCase should prevent execution of database queries

2015-04-17 Thread Django

#24652: SimpleTestCase should prevent execution of database queries
-+-
 Reporter:  charettes|Owner:  charettes
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #22394: Several built in Lookups should actually be Transforms

2015-04-17 Thread Django

#22394: Several built in Lookups should actually be Transforms
-+-
 Reporter:  smeatonj |Owner:  mjtamlyn
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  lookups  | 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
 * stage:  Ready for checkin => 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/066.6590cba8c6a42682877b9cc16b621c09%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24659: Docs of backends.smtp.EmailBackend: use_tls default should be False, not None

2015-04-17 Thread Django

#24659: Docs of backends.smtp.EmailBackend: use_tls default should be False, not
None
--+
 Reporter:  guettli   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.8
 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):

 * Attachment "24659.diff" added.


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

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

Re: [Django] #24659: Docs of backends.smtp.EmailBackend: use_tls default should be False, not None

2015-04-17 Thread Django

#24659: Docs of backends.smtp.EmailBackend: use_tls default should be False, not
None
--+
 Reporter:  guettli   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.8
 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_docs:   => 0
 * has_patch:  0 => 1
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 Does the attached patch clarify how it works?

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

Re: [Django] #24657: include template tag example contains incorrect context data

2015-04-17 Thread Django

#24657: include template tag example contains incorrect context data
---+
 Reporter:  pattypatpat|  Owner:  nobody
 Type:  Bug| Status:  closed
Component:  Documentation  |Version:  1.8
 Severity:  Normal | Resolution:  fixed
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  1  |  Easy pickings:  1
UI/UX:  0  |
---+

Comment (by Tim Graham ):

 In [changeset:"84142946c0e8dfdda18391e595bd2e53001f2ea6" 84142946]:
 {{{
 #!CommitTicketReference repository=""
 revision="84142946c0e8dfdda18391e595bd2e53001f2ea6"
 [1.7.x] Fixed #24657 -- Fixed include template tag example.

 Thanks pattypatpat for the report.

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

Re: [Django] #24657: include template tag example contains incorrect context data

2015-04-17 Thread Django

#24657: include template tag example contains incorrect context data
---+
 Reporter:  pattypatpat|  Owner:  nobody
 Type:  Bug| Status:  closed
Component:  Documentation  |Version:  1.8
 Severity:  Normal | Resolution:  fixed
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  1  |  Easy pickings:  1
UI/UX:  0  |
---+

Comment (by Tim Graham ):

 In [changeset:"f21dd827b7dcc18450f75f8c29f7b01da46eca72" f21dd82]:
 {{{
 #!CommitTicketReference repository=""
 revision="f21dd827b7dcc18450f75f8c29f7b01da46eca72"
 [1.8.x] Fixed #24657 -- Fixed include template tag example.

 Thanks pattypatpat for the report.

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

Re: [Django] #24657: include template tag example contains incorrect context data

2015-04-17 Thread Django

#24657: include template tag example contains incorrect context data
---+
 Reporter:  pattypatpat|  Owner:  nobody
 Type:  Bug| Status:  closed
Component:  Documentation  |Version:  1.8
 Severity:  Normal | Resolution:  fixed
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  1  |  Easy pickings:  1
UI/UX:  0  |
---+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"f47c796b52a3c504d487c2484153fa5d90a25a74" f47c796b]:
 {{{
 #!CommitTicketReference repository=""
 revision="f47c796b52a3c504d487c2484153fa5d90a25a74"
 Fixed #24657 -- Fixed include template tag example.

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

Re: [Django] #24652: SimpleTestCase should prevent execution of database queries

2015-04-17 Thread Django

Comment (by charettes):

> Maybe we could go with an approach where SimpleTestCase disables
database queries unless the test class sets attribute
allow_database_queries to True. Then the exception could tell why it isn't
a good idea to allow database queries, but also allow users to execute
queries if they want to do so.

This is what [https://github.com/django/django/pull/4522 the actual
implementation does]. I'll alter the message error to suggest setting the
`allow_database_queries` attribute to `True` with a big warning.

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

[Django] #24659: Docs of backends.smtp.EmailBackend: use_tls default should be False, not None

2015-04-17 Thread Django

#24659: Docs of backends.smtp.EmailBackend: use_tls default should be False, not
None
--+
 Reporter:  guettli   |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  1.8
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 https://docs.djangoproject.com/en/1.8/topics/email/#smtp-backend

 I don't understand why the defaults of the constructor are different from
 the defaults of the settings:

 use_tls=None
 use_ssl=None

 The defaults of the settings are "False". Which is more intuitive since it
 is a boolean (AFAIK).

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

Re: [Django] #24595: alter field type on MySQL "forgets" nullability (and more)

2015-04-17 Thread Django

#24595: alter field type on MySQL "forgets" nullability (and more)
-+-
 Reporter:  simonpercivall   |Owner:  Claude
 |  Paroz 
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.7
 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 Claude Paroz ):

 In [changeset:"ada0845ddaefb4437e1d49aa781fd87ed9628e8f" ada0845d]:
 {{{
 #!CommitTicketReference repository=""
 revision="ada0845ddaefb4437e1d49aa781fd87ed9628e8f"
 [1.7.x] Fixed #24595 -- Prevented loss of null info in MySQL field
 alteration

 Thanks Simon Percivall for the report, and Simon Charette and Tim
 Graham for the reviews.
 Backport of 02260ea3f61b 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/072.a943865439e61ed015d967a9aada330f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24595: alter field type on MySQL "forgets" nullability (and more)

2015-04-17 Thread Django

#24595: alter field type on MySQL "forgets" nullability (and more)
-+-
 Reporter:  simonpercivall   |Owner:  Claude
 |  Paroz 
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.7
 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 Claude Paroz ):

 In [changeset:"bbfcd9618b06556a0ae2c38456ef38bf3bea9e9d" bbfcd961]:
 {{{
 #!CommitTicketReference repository=""
 revision="bbfcd9618b06556a0ae2c38456ef38bf3bea9e9d"
 [1.8.x] Fixed #24595 -- Prevented loss of null info in MySQL field
 alteration

 Thanks Simon Percivall for the report, and Simon Charette and Tim
 Graham for the reviews.
 Backport of 02260ea3f6 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/072.b62d823098a840d01220d43cdbe9cb6e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24595: alter field type on MySQL "forgets" nullability (and more)

2015-04-17 Thread Django

#24595: alter field type on MySQL "forgets" nullability (and more)
-+-
 Reporter:  simonpercivall   |Owner:  Claude
 |  Paroz 
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.7
 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 Claude Paroz ):

 * owner:   => Claude Paroz 
 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"02260ea3f61b2fe0a0178528526101ff578c7400" 02260ea]:
 {{{
 #!CommitTicketReference repository=""
 revision="02260ea3f61b2fe0a0178528526101ff578c7400"
 Fixed #24595 -- Prevented loss of null info in MySQL field alteration

 Thanks Simon Percivall for the report, and Simon Charette and Tim
 Graham for the reviews.
 }}}

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

[Django] #24658: Schema tests fail when run in isolation

2015-04-17 Thread Django

#24658: Schema tests fail when run in isolation
-+
   Reporter:  claudep|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Testing framework  |Version:  master
   Severity:  Normal |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+
 Because tables are deleted in `tearDown`, when running an individual test,
 the tables are still existing and any `create_model` operation fail.

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

Re: [Django] #24648: Model fields that reference settings that differ between dev and prod trigger the autodetector

2015-04-17 Thread Django

#24648: Model fields that reference settings that differ between dev and prod
trigger the autodetector
--+
 Reporter:  Xof   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Migrations|  Version:  1.8
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by MarkusH):

 * cc: MarkusH (added)


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

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

Re: [Django] #24650: Migration changing db_table and managed not creating new table

2015-04-17 Thread Django

#24650: Migration changing db_table and managed not creating new table
--+
 Reporter:  duduklein |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.8
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by MarkusH):

 * component:  Migrations => Documentation
 * 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/067.3410075f7ed77349f005214c09839d3a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24591: Copy ModelState.fields and ModelState.managers instead of cloning.

2015-04-17 Thread Django

#24591: Copy ModelState.fields and ModelState.managers instead of cloning.
--+
 Reporter:  knbk  |Owner:  knbk
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Migrations|  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by MarkusH):

 * needs_docs:  0 => 1


Comment:

 Checking "Needs documentation" because the operations documentation needs
 a warning about not modifying fields and possible breaking change for 3rd
 party operations in the release notes.

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

Re: [Django] #24650: Migration changing db_table and managed not creating new table

2015-04-17 Thread Django

#24650: Migration changing db_table and managed not creating new table
---+--
 Reporter:  duduklein  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Migrations |  Version:  1.8
 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 duduklein):

 Thanks for your quick response.
 Doing it in 2 steps worked in django 1.8 (I did not test in django 1.7).

 Regarding the contenttype issue, the table (and the model) did exist. This
 issue does not appear in Django 1.8 anymore, so I'm not sure it's worth
 digging further.

 Maybe it's worth mentioning in the docs that changing a model from the
 `managed=False` state to `managed=True` and making other changes should be
 done in 2 steps, as you suggested.

 Thanks again.

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

[Django] #24657: include template tag example contains incorrect context data

2015-04-17 Thread Django

#24657: include template tag example contains incorrect context data
---+
 Reporter:  pattypatpat|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  1.8
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  1  |  UI/UX:  0
---+
 Before the example, the expected output is: `"Hello, John"`, but the value
 of `person` variable in the context is `"john"` (not `John`).

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

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

Re: [Django] #24656: Query Expressions page do not always show imports

2015-04-17 Thread Django

#24656: Query Expressions page do not always show imports
---+--
 Reporter:  pydanny|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Documentation  |  Version:  1.8
 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 jarshwah):

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


Comment:

 Are you concerned that the examples do not show imports, or that the
 import location is not obvious when looking at the specific expressions?

 If the first, that's understandable and could be made more clear.

 If the second, each class is tagged with the import location, such as
 Length: https://docs.djangoproject.com/en/1.8/ref/models/database-
 functions/#django.db.models.functions.Length

 This is somewhat consistent with other areas of the docs such as
 
https://docs.djangoproject.com/en/1.8/ref/models/fields/#django.db.models.AutoField
 with the primary difference being that there is a specific note at the top
 that calls out alternate import locations:
 https://docs.djangoproject.com/en/1.8/ref/models/fields/#module-
 django.db.models.fields

 Do we need to prominently show import locations (modules) for reference
 documentation rather than having it partially hidden within #anchors? The
 information exists in the raw docs, perhaps we could surface that somehow.

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

Re: [Django] #24656: Query Expressions page do not always show imports

2015-04-17 Thread Django

#24656: Query Expressions page do not always show imports
---+--
 Reporter:  pydanny|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Documentation  |  Version:  1.8
 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 jarshwah):

 * cc: josh.smeaton@… (added)


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

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

53 matches

Mail list logo