[Django] #27422: `makemigrations` fails to migrate ForeignKey types across app boundaries

2016-11-02 Thread Django
#27422: `makemigrations` fails to migrate ForeignKey types across app boundaries
-+-
   Reporter:  Andrew |  Owner:  nobody
  Badr   |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  1.10
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I am using django-social-auth and a custom User model. I changed my User
 model to use a BigInteger `id` field. Everything looked ok, and I pushed
 into production, then started getting not-super-informative exceptions
 about `integer out of range`. I tracked it down to this bug—specifically,
 I had a django-social-auth model with a foreignkey to User—and was able to
 reproduce it using a clean Django project. This should either work
 correctly or raise an error.

 Steps to reproduce:
 1. Create Model A
 2. Create Model B with a ForeignKey to Model A
 3. Alter the type of the ForeignKey on B, e.g. making it a BigInteger
 4. manage.py makemigrations and migrate

 Expected behavior:
 The type of the foreign-key column in the table for column B is changed to
 the new type.

 Actual behavior:
 The type of the foreign-key column in the table for column B is changed to
 the new type if and only if A and B are in the same app.

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


Re: [Django] #27416: ModelFormSet with queryset accepts invalid POST data for outer models and create unexpected empty data.

2016-11-02 Thread Django
#27416: ModelFormSet with queryset accepts invalid POST data for outer models 
and
create unexpected empty data.
-+-
 Reporter:  Hiroki Kiyohara  |Owner:  Hiroki
 |  Kiyohara
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  formset,modelform| Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Hiroki Kiyohara):

 Thanks Tim for your quick response.

 And I agree with you, If we want to prohibit the creation of new
 instances, the ticket #26142 is the best.
 Actually #26142 will solve a latest problem on my working project
 (Creation of unexpected instance by invalid POST param).
 As Tim explained, now the second question is whether invalid POST data
 should create new empty instance or not.

 I'm thinking it's not expected behavior. Because it will create
 unvalidated empty instance. not so explicit.
 But I'm not strongly sure. so I want some others opinion or I'll take time
 to re-think about it.

 I deleted `extra=0` argument on the PR (now it seems unrelated thing).
 
https://github.com/django/django/pull/7462/commits/20d4b8073c0f028ee23feb68f42cdd58549d58fa

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


Re: [Django] #27422: `makemigrations` fails to migrate ForeignKey types across app boundaries

2016-11-02 Thread Django
#27422: `makemigrations` fails to migrate ForeignKey types across app boundaries
-+-
 Reporter:  Andrew Badr  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (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 Andrew Badr):

 Note also that this is a pain to work around. It's too late to roll back
 the bigint ids (they are on all my models), and I don't know how to force
 the foreignkey type change in a 3rd party app (I can't edit django-social-
 auth's models) without bringing a local copy into my project. Right now my
 plan is to alter the production db manually.

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


Re: [Django] #27422: `makemigrations` fails to migrate ForeignKey types across app boundaries

2016-11-02 Thread Django
#27422: `makemigrations` fails to migrate ForeignKey types across app boundaries
-+-
 Reporter:  Andrew Badr  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 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 Andrew Badr):

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


Comment:

 Oops— I think I need to dig into this more. Sorry!

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


Re: [Django] #27422: `makemigrations` fails to migrate ForeignKey types across app boundaries

2016-11-02 Thread Django
#27422: `makemigrations` fails to migrate ForeignKey types across app boundaries
-+-
 Reporter:  Andrew Badr  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (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
-+-
Description changed by Andrew Badr:

Old description:

> I am using django-social-auth and a custom User model. I changed my User
> model to use a BigInteger `id` field. Everything looked ok, and I pushed
> into production, then started getting not-super-informative exceptions
> about `integer out of range`. I tracked it down to this bug—specifically,
> I had a django-social-auth model with a foreignkey to User—and was able
> to reproduce it using a clean Django project. This should either work
> correctly or raise an error.
>
> Steps to reproduce:
> 1. Create Model A
> 2. Create Model B with a ForeignKey to Model A
> 3. Alter the type of the ForeignKey on B, e.g. making it a BigInteger
> 4. manage.py makemigrations and migrate
>
> Expected behavior:
> The type of the foreign-key column in the table for column B is changed
> to the new type.
>
> Actual behavior:
> The type of the foreign-key column in the table for column B is changed
> to the new type if and only if A and B are in the same app.

New description:

 I am using django-social-auth and a custom User model. I changed my User
 model to use a BigInteger `id` field. Everything looked ok, and I pushed
 into production, then started getting not-super-informative exceptions
 about `integer out of range`. I tracked it down to this bug—specifically,
 I have a django-social-auth model with a foreignkey to User—and I was able
 to reproduce it on a clean Django project. This kind of migration should
 either work correctly or raise an error.

 Steps to reproduce:
 1. Create Model A
 2. Create Model B with a ForeignKey to Model A
 3. Alter the type of the primary key on A, e.g. making it a BigInteger
 4. manage.py makemigrations and migrate

 Expected behavior:
 The type of the foreign-key column in the table for column B is changed to
 the new type.

 Actual behavior:
 The type of the foreign-key column in the table for column B is changed to
 the new type if and only if A and B are in the same app.

--

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


[Django] #27417: Change case on field causes invalid rename on Oracle backend migration

2016-11-02 Thread Django
#27417: Change case on field causes invalid rename on Oracle backend migration
-+-
   Reporter:  Vackar |  Owner:  nobody
  Afzal  |
   Type: | Status:  new
  Uncategorized  |
  Component: |Version:  1.9
  Migrations |
   Severity:  Release|   Keywords:  Migrations, Oracle,
  blocker|  DB, Rename
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 Given the following class

 {{{
 class MyModel(models.model):
 somefield = models.CharField(max_length=100)
 }}}

 if I rename 'somefield' to 'someField' and run make migrations, it will
 generate a migrations that will rename 'somefield' to 'someField'

 On case insensitive backends like oracle, this will result in the
 following invalid SQL being generated.


 {{{
 alter table mymodel rename somefield to someField;
 }}}

 In cases like this, it should simply generate no SQL.

 The other option is when prompted for 'did you rename field x to y' , you
 can say no, which will result in a drop column followed by an add column,
 but this will result in **all of the existing data in the column being
 lost**, less than ideal.

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


[Django] #27418: Occasional missing plural forms in JS

2016-11-02 Thread Django
#27418: Occasional missing plural forms in JS
--+
   Reporter:  Waldemar Kornewald  |  Owner:  nobody
   Type:  Uncategorized   | Status:  new
  Component:  Uncategorized   |Version:  1.10
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  1
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 I've fixed a bug that occurs randomly when generating JS translations for
 plural forms. Sometimes the list of plural forms in the generated JS only
 contains two items although the language has more than two plural forms.

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

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


[Django] #27423: Test command sys.exit() does unnecessary casting to False always

2016-11-02 Thread Django
#27423: Test command sys.exit() does unnecessary casting to False always
+--
   Reporter:  Ana Balica|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  assigned
  Component:  Testing framework |Version:  1.10
   Severity:  Normal|   Keywords:  test
   Triage Stage:  Unreviewed|  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  0 |
+--
 Currently we have:

 {{{
 if failures:
 sys.exit(bool(failures))
 }}}

 If no failures, the script will exit with 0 success, if any failures, then
 the exit is forced with a `False` value, which will result in a 1.
 Why not be explicit?

 {{{
 if failures:
 sys.exit(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/053.ed4df24ae862bdbd48ab9dc825ce801e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #27408: Make QuerySet.bulk_create() populate fields on related models

2016-11-02 Thread Django
#27408: Make QuerySet.bulk_create() populate fields on related models
-+-
 Reporter:  Jarek Glowacki   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  bulk_create foreign  | Triage Stage:
  key id |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jarek Glowacki):

 I believe you're referring to this: #9553

 The proposed solution there was to proactively update all instances that
 had the just-saved instance as an FK. Big change, probably could hit
 performance pretty hard in some situations.
 If we want to solve this in the general case I'd be more inclined to just
 use a fallback in the field descriptor's `__get__`, so that we're not
 updating instances that might not end up getting accessed.

 It's tricky, because the general case really wouldn't benefit much from
 this, other than keeping things consistent. Hence I thought it might be
 better to focus on just making it work for `bulk_create` (maybe with an
 explicitly set flag even, to make it obvious).

 I'll try both approaches over the weekend and see if I can come up with
 something nice.

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


Re: [Django] #27425: Outdated FAQ, developers to hire

2016-11-02 Thread Django
#27425: Outdated FAQ, developers to hire
-+-
 Reporter:  Maciej Olko  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  faq, links, wiki,| Triage Stage:
  developers, jobs   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Maciej Olko):

 * Attachment "update_faq_developers.patch" added.

 Patch to ticket #27425 – update of FAQ 'Developers to hire' section

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


[Django] #27424: contenttype 0002_remove_content_type_name migration failure

2016-11-02 Thread Django
#27424: contenttype 0002_remove_content_type_name migration failure
+
   Reporter:  Juan Borda|  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  contrib.contenttypes  |Version:  1.8
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  0 |
+
 django/contrib/contenttype/migrations/0002_remove_content_type_name.py

 In a project that uses django 1.8 we triend to run some tests and got
 failures when django tried to set up the databse from scratch.
 We then traced this problem to a problem applying migration
 0002_remove_content_type_name.py

 the somewhat cryptic stacktrace follows:


 {{{
   Rendering model states... DONE
   Applying contenttypes.0002_remove_content_type_name...Traceback (most
 recent call last):
   File "./manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "/home/juanborda/.virtualenvs/sabios/lib/python3.5/site-
 packages/django/core/management/__init__.py", line 338, in
 execute_from_command_line
 utility.execute()
   File "/home/juanborda/.virtualenvs/sabios/lib/python3.5/site-
 packages/django/core/management/__init__.py", line 330, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/home/juanborda/.virtualenvs/sabios/lib/python3.5/site-
 packages/django/core/management/base.py", line 393, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/home/juanborda/.virtualenvs/sabios/lib/python3.5/site-
 packages/django/core/management/base.py", line 444, in execute
 output = self.handle(*args, **options)
   File "/home/juanborda/.virtualenvs/sabios/lib/python3.5/site-
 packages/django/core/management/commands/migrate.py", line 221, in handle
 executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
   File "/home/juanborda/.virtualenvs/sabios/lib/python3.5/site-
 packages/django/db/migrations/executor.py", line 110, in migrate
 self.apply_migration(states[migration], migration, fake=fake,
 fake_initial=fake_initial)
   File "/home/juanborda/.virtualenvs/sabios/lib/python3.5/site-
 packages/django/db/migrations/executor.py", line 148, in apply_migration
 state = migration.apply(state, schema_editor)
   File "/home/juanborda/.virtualenvs/sabios/lib/python3.5/site-
 packages/django/db/migrations/migration.py", line 115, in apply
 operation.database_forwards(self.app_label, schema_editor, old_state,
 project_state)
   File "/home/juanborda/.virtualenvs/sabios/lib/python3.5/site-
 packages/django/db/migrations/operations/special.py", line 178, in
 database_forwards
 if router.allow_migrate(schema_editor.connection.alias, app_label,
 **self.hints):
   File "/home/juanborda/.virtualenvs/sabios/lib/python3.5/site-
 packages/django/db/utils.py", line 347, in allow_migrate
 allow = method(db, app_label, **hints)
 TypeError: allow_migrate() missing 1 required positional argument: 'model'
 }}}



 We overcame this by deleting the file and re-generating the migration.
 this freshly created migration now allows us to create virgin databases as
 well as setup the test environment.

 Atached is the new generated migration file that hopefull you can include
 in future packaged versions of 1.8 django or any others that might have
 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.72d9d593c39856163c1be0965d41e747%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #27425: Outdated FAQ, developers to hire

2016-11-02 Thread Django
#27425: Outdated FAQ, developers to hire
-+-
   Reporter:  Maciej |  Owner:  nobody
  Olko   |
   Type:  Bug| Status:  new
  Component: |Version:  master
  Documentation  |   Keywords:  faq, links, wiki,
   Severity:  Normal |  developers, jobs
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 Section [https://docs.djangoproject.com/en/1.10/faq/general/#where-can-i
 -find-django-developers-for-hire ''Where can I find Django developers for
 hire?''] of ''FAQ: General'' is outdated as
 [https://code.djangoproject.com/wiki/DevelopersForHire
 ''DevelopersForHire'' wiki page] ''is no longer used for job listings''. I
 suggest moving [https://people.djangoproject.com/ Django People] as first
 proposition, then placing [https://djangogigs.com/developers/
 djangogigs.com/developers] and [http://djangojobsboard.com/developer-
 profiles/ djangojobsboard.com/developer-profiles] for lists of developers.
 And then suggestion of posting a job to [https://djangogigs.com/
 djangogigs.com], [https://www.djangojobs.net/ djangojobs.net],
 [http://djangojobbers.com/ djangojobbers.com] and
 [http://djangojobsboard.com djangojobsboard.com]. Please see the patch
 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/050.9465cb3099a26a59d825f9e4b3e75ba6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #27426: Client is not a RequestFactory

2016-11-02 Thread Django
#27426: Client is not a RequestFactory
-+-
 Reporter:  Ana Balica   |Owner:  Ana
 Type:   |  Balica
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  test, client,| Triage Stage:
  requestfactory |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ana Balica):

 * status:  new => assigned
 * owner:  nobody => Ana Balica


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


Re: [Django] #27423: Test command sys.exit() does unnecessary casting to False always

2016-11-02 Thread Django
#27423: Test command sys.exit() does unnecessary casting to False always
-+-
 Reporter:  Ana Balica   |Owner:  Ana
 Type:   |  Balica
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  test | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Ana Balica):

 * owner:  nobody => Ana Balica


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


Re: [Django] #27425: Outdated FAQ, developers to hire

2016-11-02 Thread Django
#27425: Outdated FAQ, developers to hire
-+-
 Reporter:  Maciej Olko  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  faq, links, wiki,| Triage Stage:
  developers, jobs   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Description changed by Maciej Olko:

Old description:

> Section [https://docs.djangoproject.com/en/1.10/faq/general/#where-can-i
> -find-django-developers-for-hire ''Where can I find Django developers for
> hire?''] of ''FAQ: General'' is outdated as
> [https://code.djangoproject.com/wiki/DevelopersForHire
> ''DevelopersForHire'' wiki page] ''is no longer used for job listings''.
> I suggest moving [https://people.djangoproject.com/ Django People] as
> first proposition, then placing [https://djangogigs.com/developers/
> djangogigs.com/developers] and [http://djangojobsboard.com/developer-
> profiles/ djangojobsboard.com/developer-profiles] for lists of
> developers. And then suggestion of posting a job to
> [https://djangogigs.com/ djangogigs.com], [https://www.djangojobs.net/
> djangojobs.net], [http://djangojobbers.com/ djangojobbers.com] and
> [http://djangojobsboard.com djangojobsboard.com]. Please see the patch
> attached.

New description:

 Section [https://docs.djangoproject.com/en/1.10/faq/general/#where-can-i
 -find-django-developers-for-hire ''Where can I find Django developers for
 hire?''] of ''FAQ: General'' is outdated as
 [https://code.djangoproject.com/wiki/DevelopersForHire
 ''DevelopersForHire'' wiki page] ''is no longer used for job listings''.

 I suggest moving [https://people.djangoproject.com/ Django People] as
 first proposition, then placing [https://djangogigs.com/developers/
 djangogigs.com/developers] and [http://djangojobsboard.com/developer-
 profiles/ djangojobsboard.com/developer-profiles] for lists of developers.
 And then suggestion of posting a job to [https://djangogigs.com/
 djangogigs.com], [https://www.djangojobs.net/ djangojobs.net],
 [http://djangojobbers.com/ djangojobbers.com] and
 [http://djangojobsboard.com djangojobsboard.com]. Please see the patch
 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.e07bac37f4052899851a7ff32e11fdaa%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #27424: contenttype 0002_remove_content_type_name migration failure

2016-11-02 Thread Django
#27424: contenttype 0002_remove_content_type_name migration failure
-+-
 Reporter:  Juan Borda   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.8
  contrib.contenttypes   |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Juan Borda):

 * Attachment "0002_remove_content_type_name.py" added.

 the newly generated migration file

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


[Django] #27426: Client is not a RequestFactory

2016-11-02 Thread Django
#27426: Client is not a RequestFactory
-+-
   Reporter:  Ana|  Owner:  nobody
  Balica |
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Testing|Version:  1.10
  framework  |   Keywords:  test, client,
   Severity:  Normal |  requestfactory
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Currently the test Client is inheriting from RequestFactory for code
 reuse. Client is not a specialisation of the RequestFactory and the
 relationship between the two is conceptually incorrect.

 Much easier would be to use composition. With that it also becomes
 possible to use any other type of request factory with the Client. Open
 for discussion if there is actually any need for a different request
 factory besides the default one.

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

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


Re: [Django] #27424: contenttype 0002_remove_content_type_name migration failure

2016-11-02 Thread Django
#27424: contenttype 0002_remove_content_type_name migration failure
-+-
 Reporter:  Juan Borda   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  1.8
  contrib.contenttypes   |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Simon Charette):

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


Comment:

 Hi Juan,

 Thanks for your report.

 From your provided traceback it looks like you are not using the latest
 minor version of Django 1.8 so it's kind of hard to figure out whether or
 not Django is at fault.

 From what I can see one of your database routers' `allow_migrate()` method
 have the incorrect signature. The
 [https://docs.djangoproject.com/en/1.8/releases/1.8/#signature-of-the-
 allow-migrate-router-method signature changed in Django 1.8] but
 
[https://github.com/django/django/blob/90c61538bae7b6e86b846fcd1ab7887d9cdb2cbf/django/db/utils.py#L335-L352
 there's code in place] to make sure the old signature works until Django
 1.10.

 Please try upgrading to the latest Django 1.8 release and re-open this
 ticket with details about the Python version you are using and the
 definition of your database routers the `DATABASE_ROUTERS` is pointing to.

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


Re: [Django] #27408: Make QuerySet.bulk_create() populate fields on related models

2016-11-02 Thread Django
#27408: Make QuerySet.bulk_create() populate fields on related models
-+-
 Reporter:  Jarek Glowacki   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  bulk_create foreign  | Triage Stage:
  key id |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 From what I remember there's already a ticket about keeping a foreign key
 attribute and its underlying `_id` one synchronized which is the real
 issue here as demonstrated by the failing example using save in comment:1.

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

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


[Django] #27420: Oracle DB test user password error

2016-11-02 Thread Django
#27420: Oracle DB test user password error
-+-
   Reporter:  felixxm|  Owner:  felixxm
   Type:  Bug| Status:  assigned
  Component:  Database   |Version:  master
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Oracle DB test user password can not start with digits because quotation
 marks are missing in SQL. For example:

 {{{#!sql
 CREATE USER foo
 IDENTIFIED BY 2fXHVnA9KRH4uTSSvV3fVDel4kyVum
 DEFAULT TABLESPACE foo_tbls_test
 TEMPORARY TABLESPACE foo_tbls_temp_test
 QUOTA UNLIMITED ON foo_tbls_test;
 }}}

 is incorrect (`ORA-00922: missing or invalid option`) it should be:

 {{{#!sql
 CREATE USER foo
 IDENTIFIED BY "2fXHVnA9KRH4uTSSvV3fVDel4kyVum"
 DEFAULT TABLESPACE foo_tbls_test
 TEMPORARY TABLESPACE foo_tbls_temp_test
 QUOTA UNLIMITED ON foo_tbls_test;
 }}}

 All versions are vulnerable ie 1.8.16, 1.9.11, 1.10.3 and 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/050.10bf7e895c1cf4ff44e533b0093f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #27419: Model that worked before 1.10 causes "Cannot force an update in save() with no primary key." in 1.10.

2016-11-02 Thread Django
#27419: Model that worked before 1.10 causes "Cannot force an update in save() 
with
no primary key." in 1.10.
-+-
 Reporter:  Louis-Dominique  |Owner:  nobody
  Dubeau |
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  save model property  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Louis-Dominique Dubeau):

 * Attachment "tests.py" 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.fe93ecd5f8616fb1f4c76bd2ce37bfc9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #27419: Model that worked before 1.10 causes "Cannot force an update in save() with no primary key." in 1.10.

2016-11-02 Thread Django
#27419: Model that worked before 1.10 causes "Cannot force an update in save() 
with
no primary key." in 1.10.
-+-
 Reporter:  Louis-Dominique  |Owner:  nobody
  Dubeau |
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  save model property  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Louis-Dominique Dubeau):

 * Attachment "models.py" 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.45fe227868dd1dcae63258a09ab8ef35%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #27415: Add request.JSON or request.get_json()

2016-11-02 Thread Django
#27415: Add request.JSON or request.get_json()
-+-
 Reporter:  Ustun Ozgur  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core |  Version:  1.10
  (Serialization)|
 Severity:  Normal   |   Resolution:
 Keywords:  json, request,   | Triage Stage:
  incoming data  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 Hi Unstun,

 Thanks for your suggestion but I believe we should focus on making
 `request.data` available based on the `Content-Type` header like described
 in the DEP you linked instead of adding a `JSON` attribute on request that
 would be removed in the mid-term. In the meantime you can write a
 middleware that adds a `JSON` attribute on request with the appropriate
 content-type if you want to rely on that.

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


[Django] #27419: Model that worked before 1.10 causes "Cannot force an update in save() with no primary key." in 1.10.

2016-11-02 Thread Django
#27419: Model that worked before 1.10 causes "Cannot force an update in save() 
with
no primary key." in 1.10.
-+-
   Reporter:  Louis- |  Owner:  nobody
  Dominique Dubeau   |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  1.10
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  save model property
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 This problem does not happen prior to Django 1.10. I'm running this on
 Python 2.7.12 but I don't think the Python version is an issue. The
 following case is distilled form a full-fledged application that has run
 fine in production since Django 1.6. Upon upgrading to 1.10, I immediately
 got the error reported here.

 Consider the following models.py file:

 {{{
 from __future__ import unicode_literals

 from django.db import models

 class Foo(models.Model):

 a = models.CharField(max_length=10)
 b = models.CharField(max_length=10)
 parent = models.ForeignKey(
 "self", related_name="children", null=True, blank=True)

 class Bar(models.Model):

 a = models.CharField(max_length=10)
 _b = models.CharField(max_length=10, name="b", db_column="b")
 parent = models.ForeignKey(
 "self", related_name="children", null=True, blank=True)

 @property
 def b(self):
 return self._b

 @b.setter
 def b(self, val):
 print "SETTING B"
 # This would make the problem disappear:
 # self.__dict__["b"] = val
 self._b = val
 }}}

 And the following tests.py file which is a sibling to models.py above:

 {{{
 from django.test import TestCase

 from .models import *

 class TestFoo(TestCase):

 def test(self):
 parent = Foo(a="parent_a", b="parent_b")
 parent.save()
 foo = Foo(a="1a", b="1b", parent=parent)
 foo.save()

 class TestBar(TestCase):

 def test(self):
 parent = Bar(a="parent_a", b="parent_b")
 parent.save()
 bar = Bar(a="1a", b="1b", parent=parent)
 bar.save()
 }}}

 Running `./manage.py test` results in:

 {{{
 $ ./manage.py test
 Creating test database for alias 'default'...
 SETTING B
 SETTING B
 E.
 ==
 ERROR: test (myapp.tests.TestBar)
 --
 Traceback (most recent call last):
   File
 "/home/ldd/src/django_issues/deferred_fields_in_1.10/issue/myapp/tests.py",
 line 19, in test
 bar.save()
   File "/home/ldd/src/django_issues/deferred_fields_in_1.10/issue-
 venv/local/lib/python2.7/site-packages/django/db/models/base.py", line
 796, in save
 force_update=force_update, update_fields=update_fields)
   File "/home/ldd/src/django_issues/deferred_fields_in_1.10/issue-
 venv/local/lib/python2.7/site-packages/django/db/models/base.py", line
 824, in save_base
 updated = self._save_table(raw, cls, force_insert, force_update,
 using, update_fields)
   File "/home/ldd/src/django_issues/deferred_fields_in_1.10/issue-
 venv/local/lib/python2.7/site-packages/django/db/models/base.py", line
 880, in _save_table
 raise ValueError("Cannot force an update in save() with no primary
 key.")
 ValueError: Cannot force an update in save() with no primary key.

 --
 Ran 2 tests in 0.002s

 FAILED (errors=1)
 Destroying test database for alias 'default'...
 }}}

 If I downgrade to Django 1.9, I get:

 {{{
 $ ./manage.py test
 Creating test database for alias 'default'...
 SETTING B
 SETTING B
 ..
 --
 Ran 2 tests in 0.001s

 OK
 Destroying test database for alias 'default'...
 }}}

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

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


[Django] #27421: Add support for size, shape, and offset parameters on instantiation of GDALRaster objects.

2016-11-02 Thread Django
#27421: Add support for size, shape, and offset parameters on instantiation of
GDALRaster objects.
-+-
   Reporter:  Daniel |  Owner:  Daniel Wiesmann
  Wiesmann   |
   Type:  New| Status:  assigned
  feature|
  Component:  GIS|Version:  master
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 The
 
[https://docs.djangoproject.com/en/dev/ref/contrib/gis/gdal/#django.contrib.gis.gdal.GDALBand.data
 data() method on GDALBand objects for setting pixel values] accepts
 parameters that allow fine grained control over the pixel values. The
 parameters are `size`, `shape`, and `offset`. Band data values can be
 replicated (for fast writing of blocks of equal data values for instance)
 and specific blocks of data can be written.

 This functionality should also be available directly when instantiating
 GDALRaster objects. So that band data values can be controlled with more
 detail on raster creation.

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

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


Re: [Django] #27415: Add request.JSON or request.get_json()

2016-11-02 Thread Django
#27415: Add request.JSON or request.get_json()
-+-
 Reporter:  Ustun Ozgur  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  HTTP handling|  Version:  1.10
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  json, request,   | Triage Stage:
  incoming data  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * status:  new => closed
 * resolution:   => wontfix
 * component:  Core (Serialization) => HTTP handling


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


Re: [Django] #27418: Occasional missing plural forms in JavaScriptCatalog (was: Occasional missing plural forms in JS)

2016-11-02 Thread Django
#27418: Occasional missing plural forms in JavaScriptCatalog
--+
 Reporter:  Waldemar Kornewald|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Internationalization  |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tim Graham):

 * type:  Uncategorized => Bug
 * component:  Uncategorized => Internationalization
 * needs_tests:  0 => 1
 * 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/068.c154dcb5bc19def26b4f4154f56690fc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #27419: Model that worked before 1.10 causes "Cannot force an update in save() with no primary key." in 1.10.

2016-11-02 Thread Django
#27419: Model that worked before 1.10 causes "Cannot force an update in save() 
with
no primary key." in 1.10.
-+-
 Reporter:  Louis-Dominique  |Owner:  nobody
  Dubeau |
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  save model property  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 It's not obvious that this is a Django bug since you're doing some non-
 standard stuff with `setter`. Could you try
 [https://docs.djangoproject.com/en/dev/internals/contributing/triaging-
 tickets/#bisecting-a-regression bisecting] to find the commit where the
 behavior changed? A similar issue was [https://groups.google.com/d/topic
 /django-users/lwijFEquQI8/discussion reported on django-users].

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


Re: [Django] #27420: Oracle DB test user password must be quoted if it starts with a number

2016-11-02 Thread Django
#27420: Oracle DB test user password must be quoted if it starts with a number
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 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
-+-
Description changed by felixxm:

Old description:

> Oracle DB test user password can not start with digits because quotation
> marks are missing in SQL. For example:
>
> {{{#!sql
> CREATE USER foo
> IDENTIFIED BY 2fXHVnA9KRH4uTSSvV3fVDel4kyVum
> DEFAULT TABLESPACE foo_tbls_test
> TEMPORARY TABLESPACE foo_tbls_temp_test
> QUOTA UNLIMITED ON foo_tbls_test;
> }}}
>
> is incorrect (`ORA-00922: missing or invalid option`) it should be:
>
> {{{#!sql
> CREATE USER foo
> IDENTIFIED BY "2fXHVnA9KRH4uTSSvV3fVDel4kyVum"
> DEFAULT TABLESPACE foo_tbls_test
> TEMPORARY TABLESPACE foo_tbls_temp_test
> QUOTA UNLIMITED ON foo_tbls_test;
> }}}
>
> All versions are vulnerable ie 1.8.16, 1.9.11, 1.10.3 and master.

New description:

 Oracle DB test user password cannot start with digits because quotation
 marks are missing in SQL. For example:

 {{{#!sql
 CREATE USER foo
 IDENTIFIED BY 2fXHVnA9KRH4uTSSvV3fVDel4kyVum
 DEFAULT TABLESPACE foo_tbls_test
 TEMPORARY TABLESPACE foo_tbls_temp_test
 QUOTA UNLIMITED ON foo_tbls_test;
 }}}

 is incorrect (`ORA-00922: missing or invalid option`) it should be:

 {{{#!sql
 CREATE USER foo
 IDENTIFIED BY "2fXHVnA9KRH4uTSSvV3fVDel4kyVum"
 DEFAULT TABLESPACE foo_tbls_test
 TEMPORARY TABLESPACE foo_tbls_temp_test
 QUOTA UNLIMITED ON foo_tbls_test;
 }}}

 All versions are vulnerable ie 1.8.16, 1.9.11, 1.10.3 and master.

--

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

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


Re: [Django] #27420: Oracle DB test user password must be quoted if it starts with a number

2016-11-02 Thread Django
#27420: Oracle DB test user password must be quoted if it starts with a number
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Shai Berger):

 Replying to [comment:1 Tim Graham]:
 > This might explain some of the failures that have popped up on Jenkins.

 I believe they are actually unrelated, the error was about password
 expiry.

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


[Django] #27416: ModelFormSet with queryset accepts invalid POST data for outer models and create unexpected empty data.

2016-11-02 Thread Django
#27416: ModelFormSet with queryset accepts invalid POST data for outer models 
and
create unexpected empty data.
-+-
   Reporter:  Hiroki |  Owner:  Hiroki Kiyohara
  Kiyohara   |
   Type:  Bug| Status:  assigned
  Component:  Forms  |Version:  1.10
   Severity:  Normal |   Keywords:  formset,modelform
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 ModelFormSet with queryset argument will accept invalid POST data and
 create unexpected empty data.
 Invalid data means that data won't be appear in `queryset=...`, like this.

 {{{#!python
 author = Author.objects.create(pk=1, name='Walt Whitman')
 other_author = Author.objects.create(pk=2, name='Charles
 Baudelaire')
 AuthorFormSet = modelformset_factory(Author, fields="__all__",
 extra=0)

 data = {
 'form-TOTAL_FORMS': '2',  # the number of forms rendered
 'form-INITIAL_FORMS': '2',  # the number of forms with initial
 data
 'form-MAX_NUM_FORMS': '',  # the max number of forms
 'form-0-id': str(author.id),
 'form-0-name': 'Walt Whitman',
 'form-1-id': str(other_author.id),  # Specifying outer model
 of bellow queryset.
 'form-1-name': 'Changed name',
 }
 # This formset is only for Walt Whitman
 # and should not accept POST data for other_author
 formset = AuthorFormSet(data=data,
 queryset=Author.objects.filter(id__in=(author.id,)))
 }}}

 This formset should ignore unexpected `form-1-id': str(other_author.id)`
 value, a value not in queryset.
 The value in `other_author` won't be changed, but this formset will create
 unexpected new **empty data** (which has `Author.name = ""`).

 === Why

 Internally...

 1. In Formsets, forms corresponding to invalid data will be instantiated
 with `instance=None` (due to this line
 https://github.com/django/django/blob/master/django/forms/models.py#L597)
 2. ModelForm will set form.instance as empty instance (`self.instance =
 opts.model()`)
 3. Saving `formset.save()` will save this unexpected invalid data

 === Why it's problem

 It will create unexpected empty data and may cause IntegrityError.
 For instance, if Artist.name field has unique constraint, and invalid POST
 data come sometimes,
 it will create empty Artist data more than twice and cause UNIQUE
 constraint error.

 === PS

 Is this recognized as bug? or should I specify more extra args for
 formset?
 I searched similar tickets but not existed.
 (Just ticket I found is #26142 to prevent to create new instance for
 FormSet, It may prevent this problem too but not correct way to solve).

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


Re: [Django] #27416: ModelFormSet with queryset accepts invalid POST data for outer models and create unexpected empty data.

2016-11-02 Thread Django
#27416: ModelFormSet with queryset accepts invalid POST data for outer models 
and
create unexpected empty data.
-+-
 Reporter:  Hiroki Kiyohara  |Owner:  Hiroki
 |  Kiyohara
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  formset,modelform| Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Hiroki Kiyohara):

 * has_patch:  0 => 1


Comment:

 Opened a Pull Request https://github.com/django/django/pull/7462

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


Re: [Django] #27421: Add support for size, shape, and offset parameters on instantiation of GDALRaster objects.

2016-11-02 Thread Django
#27421: Add support for size, shape, and offset parameters on instantiation of
GDALRaster objects.
-+-
 Reporter:  Daniel Wiesmann  |Owner:  Daniel
 |  Wiesmann
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  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 Daniel Wiesmann):

 * has_patch:  0 => 1


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

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


Re: [Django] #27420: Oracle DB test user password must be quoted if it starts with a number (was: Oracle DB test user password error)

2016-11-02 Thread Django
#27420: Oracle DB test user password must be quoted if it starts with a number
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * severity:  Normal => Release blocker
 * version:  master => 1.8
 * needs_docs:  0 => 1
 * has_patch:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 [https://github.com/django/django/pull/7463 PR]. This might explain some
 of the failures that have popped up on Jenkins. Release notes for 1.10.4,
 1.9.12, and 1.8.17 are also needed.

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

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


Re: [Django] #27421: Add support for size, shape, and offset parameters on instantiation of GDALRaster objects.

2016-11-02 Thread Django
#27421: Add support for size, shape, and offset parameters on instantiation of
GDALRaster objects.
-+-
 Reporter:  Daniel Wiesmann  |Owner:  Daniel
 |  Wiesmann
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  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 Tim Graham):

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


Re: [Django] #27420: Oracle DB test user password must be quoted if it starts with a number

2016-11-02 Thread Django
#27420: Oracle DB test user password must be quoted if it starts with a number
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 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 felixxm):

 * needs_docs:  1 => 0


Comment:

 I added release notes for 1.8.17/1.9.12/1.10.4.

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


Re: [Django] #27416: ModelFormSet with queryset accepts invalid POST data for outer models and create unexpected empty data.

2016-11-02 Thread Django
#27416: ModelFormSet with queryset accepts invalid POST data for outer models 
and
create unexpected empty data.
-+-
 Reporter:  Hiroki Kiyohara  |Owner:  Hiroki
 |  Kiyohara
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  formset,modelform| Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 My first instinct is that this is a duplicate of #26142 but the fact that
 the extra instances are created without the supplied data leaves a
 question as to whether or not the current behavior is actually useful. As
 #27416 says, `extra=0` isn't really meant to prohibit the creation of new
 instances. Without digging into the details, I'd say it might be
 appropriate to fix the current behavior to create instances with the
 provided data (as a separate ticket) and then in this ticket add a new
 `modelformset_factory()` parameter to prohibit the creation of new
 instances.

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