date:20150304

Re: [Django] #24369: flush requires migrations

2015-03-04 Thread Django

#24369: flush requires migrations
-+-
 Reporter:  tanner   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Management |  Version:  1.7
  commands)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  flush| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"767c33d1fa9827908192e8ed1ac7f281f56bd811"]:
 {{{
 #!CommitTicketReference repository=""
 revision="767c33d1fa9827908192e8ed1ac7f281f56bd811"
 Fixed #24369 -- Prevented crash when flushing before db migration

 Thanks Thomas Tanner for the report and Tim Graham for the 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/064.9c396b538e769cc8fcbf0fba16e70ec9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24420: Can't order_by annotated field if annotated field uses conditional expression

2015-03-04 Thread Django

#24420: Can't order_by annotated field if annotated field uses conditional
expression
-+-
 Reporter:  krisfields   |Owner:  jarshwah
 Type:  Bug  |   Status:  assigned
Component:  Uncategorized|  Version:  1.8beta1
 Severity:  Normal   |   Resolution:
 Keywords:  order_by,| Triage Stage:  Accepted
  annotation, conditional|
  expression |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by jarshwah):

 See: https://github.com/django/django/pull/4239

 Funnily enough, being explicit worked before this patch:

 CaseTestModel.objects.filter(integer__lte=2).annotate(test=Case(
 When(integer=1, then=2),
 When(integer=2, then=1),
 default=3,
 output_field=models.IntegerField(),
 )).order_by(F('test').asc())

 The problem is that the same instance of each `When` clause has
 resolve_expression called on it multiple times. Once for the annotation,
 and once again for the order_by. The problem is that
 When.resolve_expression converts the Q() into a WhereNode(), and
 overwrites the condition property. It's not idempotent.

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

Re: [Django] #24430: wildcard matching and reversing of URLs

2015-03-04 Thread Django

Comment (by charettes):

I suggest you have a look at how `LocaleRegexURLResolver` work. You just
have to write and URLResolver that get or create a tenant specific admin
site in a thread safe way and delegate the true url resolving to
`tenant_adminsite.urls`. It's definitely doable.

If you need help creating such a resolver I suggest you have a look at our
[https://docs.djangoproject.com/en/1.7/faq/help/ different support
channels] since this ticket tracker isn't the right place to get help.

Keep in mind that your use case is very specific and that even if we added
a request argument to the `reverse` tag we'd have to either make the
request a thread local object (this is not going to happen) or convert all
the admin reverse calls (direct or through `{% url %}`) to pass the
request along. And I'm not even talking about third party admin apps that
would require to also be converted.

There's already a supported and documented way of namespacing and
deploying multiple admin sites and from what I can see it's perfectly
suitable for your use case.

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

Re: [Django] #24430: wildcard matching and reversing of URLs

2015-03-04 Thread Django

Comment (by eskhool):

Replying to [comment:5 charettes]:
> [https://docs.djangoproject.com/en/1.7/ref/contrib/admin/#multiple-
admin-sites Multiple admin sites can already be deployed in same URLConf].
>
> You'd just have to create a namespaced admin site for each of you
tenants or write an URLResolver that does it for you.

Multiple admin sites are fine but seem to require each tenant to have a
code entry in the URL Conf. Problem is that we need the namespaced admin
sites to be dynamic since tenants needs to be added at any time without
code intervention.

we write a URL Resolver, how will we get Django admin to use that URL
resolver instead of the default django.core.urlresolvers.reverse etc?

this is why the wildcard support was proposed

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

Re: [Django] #19538: Remove __admin_media_prefix__ in admin templates

2015-03-04 Thread Django

#19538: Remove __admin_media_prefix__ in admin templates
-+-
 Reporter:  andrew@… |Owner:  timgraham
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  admin S3 DateTime| 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 collinanderson):

 * stage:  Accepted => Ready for checkin


Comment:

 I don't want to rush it, but the PR looks good.

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

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

Re: [Django] #24447: Migrations do not add a FK constraint for an existing column (was: Migrations do not execute create_fk_sql() when adding a foreign key to a field)

2015-03-04 Thread Django

#24447: Migrations do not add a FK constraint for an existing column
+
 Reporter:  ganwell |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.7
 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
+

Old description:

> Migrations failed when introducing foreign keys on existing fields.
>
> Pull request: https://github.com/django/django/pull/4235
> Branch with fix:
> https://github.com/ganwell/django/tree/master_missing_create_fk_sql
> Branch with unittest but no fix:
> https://github.com/ganwell/django/tree/master_missing_create_fk_sql_fail
>
> Consider following model:
>
> {{{
> class ForeignKeyTest(models.Model):
> id = models.AutoField(primary_key=True)
> customer = models.IntegerField()
>
> class Customer(models.Model):
> id = models.AutoField(primary_key=True)
> }}}
>
> Then it gets migrated to this:
>
> {{{
> class ForeignKeyTest(models.Model):
> id = models.AutoField(primary_key=True)
> customer = models.ForeignKey('Customer')
>
> class Customer(models.Model):
> id = models.AutoField(primary_key=True)
> }}}
>
> The second migration won't create the foreign key. This does not fail
> with sqlite! Because these migrations are handled differently. It will
> fail with MySQL and probably Postgres too. I wrote a unittest and tested
> it with MySQL: master_missing_create_fk_sql_fail fails and
> master_missing_create_fk_sql is ok.
>
> The code didn't detect this case - if old_field.rel doesn't exist
> alter_field() must always create the foreign key and ONLY if .rel exists
> it must check .db_constraint, too. Since no .rel also means there was no
> foreign key before.
>
> I will of course redo the pull request to get clean history. I also fixed
> this in 1.7.

New description:

 Pull request: https://github.com/django/django/pull/4235

 Consider following model:

 {{{
 class ForeignKeyTest(models.Model):
 id = models.AutoField(primary_key=True)
 customer = models.IntegerField()

 class Customer(models.Model):
 id = models.AutoField(primary_key=True)
 }}}

 Then it gets migrated to this:

 {{{
 class ForeignKeyTest(models.Model):
 id = models.AutoField(primary_key=True)
 customer = models.ForeignKey('Customer')

 class Customer(models.Model):
 id = models.AutoField(primary_key=True)
 }}}

 The second migration won't create the foreign key. This does not fail with
 sqlite! Because these migrations are handled differently. It will fail
 with MySQL and probably Postgres too.

 The code didn't detect this case: if old_field.rel doesn't exist
 alter_field() must always create the foreign key and ONLY if .rel exists
 it must check .db_constraint, too. Since no .rel also means there was no
 foreign key before.

--

Comment (by ganwell):

 Removed redundant information and chose clearer title.

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

Re: [Django] #24447: Migrations do not execute create_fk_sql() when adding a foreign key to a field

2015-03-04 Thread Django

#24447: Migrations do not execute create_fk_sql() when adding a foreign key to a
field
+
 Reporter:  ganwell |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.7
 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):

 * cc: MarkusH (added)
 * needs_docs:  0 => 1


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

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

Re: [Django] #24447: Migrations do not execute create_fk_sql() when adding a foreign key to a field

2015-03-04 Thread Django

#24447: Migrations do not execute create_fk_sql() when adding a foreign key to a
field
+
 Reporter:  ganwell |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.7
 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 MarkusH):

 * version:  master => 1.7


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

Re: [Django] #19538: Remove __admin_media_prefix__ in admin templates

2015-03-04 Thread Django

#19538: Remove __admin_media_prefix__ in admin templates
-+-
 Reporter:  andrew@… |Owner:  timgraham
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  admin S3 DateTime| 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:  1 => 0


Comment:

 Addressed todos; ready for review 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/079.3f1e84565a7beb20b2f238be0191928b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24447: Migrations do not execute create_fk_sql() when adding a foreign key to a field

2015-03-04 Thread Django

#24447: Migrations do not execute create_fk_sql() when adding a foreign key to a
field
+
 Reporter:  ganwell |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  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:   => 1
 * needs_docs:   => 0
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #24445: DurationField with default='1 00:00' triggers validation on otherwise empty inline formsets

2015-03-04 Thread Django

#24445: DurationField with default='1 00:00' triggers validation on otherwise 
empty
inline formsets
-+--
 Reporter:  yoyoma   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by yoyoma):

 * severity:  Normal => Release blocker


Comment:

 I've set the severity to release blocker, since this is essentially the
 same regression (thought via different means) as #24391. I've looked
 through the code a bit and can't find anything obvious that could be
 causing this issue. I'm going to look some more tomorrow night.

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

Re: [Django] #24428: Model field with default=callable and choices is always reported as changed

2015-03-04 Thread Django

#24428: Model field with default=callable and choices is always reported as 
changed
--+-
 Reporter:  CarstenF  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Forms |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Ready for checkin
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+-
Changes (by timgraham):

 * stage:  Accepted => Ready for checkin


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

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

[Django] #24447: Migrations do not execute create_fk_sql() when adding a foreign key to a field

2015-03-04 Thread Django

#24447: Migrations do not execute create_fk_sql() when adding a foreign key to a
field
+
 Reporter:  ganwell |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Migrations  |Version:  master
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  1
Easy pickings:  0   |  UI/UX:  0
+
 Migrations failed when introducing foreign keys on existing fields.

 Pull request: https://github.com/django/django/pull/4235
 Branch with fix:
 https://github.com/ganwell/django/tree/master_missing_create_fk_sql
 Branch with unittest but no fix:
 https://github.com/ganwell/django/tree/master_missing_create_fk_sql_fail

 Consider following model:

 {{{
 class ForeignKeyTest(models.Model):
 id = models.AutoField(primary_key=True)
 customer = models.IntegerField()

 class Customer(models.Model):
 id = models.AutoField(primary_key=True)
 }}}

 Then it gets migrated to this:

 {{{
 class ForeignKeyTest(models.Model):
 id = models.AutoField(primary_key=True)
 customer = models.ForeignKey('Customer')

 class Customer(models.Model):
 id = models.AutoField(primary_key=True)
 }}}

 The second migration won't create the foreign key. This does not fail with
 sqlite! Because these migrations are handled differently. It will fail
 with MySQL and probably Postgres too. I wrote a unittest and tested it
 with MySQL: master_missing_create_fk_sql_fail fails and
 master_missing_create_fk_sql is ok.

 The code didn't detect this case - if old_field.rel doesn't exist
 alter_field() must always create the foreign key and ONLY if .rel exists
 it must check .db_constraint, too. Since no .rel also means there was no
 foreign key before.

 I will of course redo the pull request to get clean history. I also fixed
 this in 1.7.

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

Re: [Django] #24428: Model field with default=callable and choices is always reported as changed

2015-03-04 Thread Django

#24428: Model field with default=callable and choices is always reported as 
changed
--+
 Reporter:  CarstenF  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Forms |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by CarstenF):

 Gee, Tim and Claude, many thanks!!

 Just when I was reading the contributor's docs to attempt a patch myself.
 ;-)  But I would probably have not been able to come up with the proper
 tests anyway (well, with a bit of luck, next time), so I'm very happy you
 did!

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

Re: [Django] #24428: Model field with default=callable and choices is always reported as changed

2015-03-04 Thread Django

#24428: Model field with default=callable and choices is always reported as 
changed
--+
 Reporter:  CarstenF  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Forms |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by claudep):

 * has_patch:  0 => 1
 * version:  1.7 => master


Comment:

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

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

Re: [Django] #24426: Admin actions panel is always hidden if show_full_result_count = False

2015-03-04 Thread Django

#24426: Admin actions panel is always hidden if show_full_result_count = False
-+-
 Reporter:  shultais |Owner:  timgraham
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.8beta1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"20bf3205027fe581b8f33cd98b164f16a801c813"]:
 {{{
 #!CommitTicketReference repository=""
 revision="20bf3205027fe581b8f33cd98b164f16a801c813"
 [1.8.x] Fixed #24426 -- Displayed admin actions panel when
 show_full_result_count=False.

 Backport of 36a17be9f3cf6081f7e6f83fcfeae3d09ce8a72b from master
 }}}

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

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

Re: [Django] #24444: Update django admin visual style to make it look modern

2015-03-04 Thread Django

#2: Update django admin visual style to make it look modern
-+-
 Reporter:  elky |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  1.8beta1
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  django-admin,| Triage Stage:
  redesign   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-

Comment (by jezdez):

 Please be aware that basing the admin UI on the website design is going to
 make it very hard to keep the visual identity of Django separate from the
 software, making it a no-go.

 Instead we shall find a solution that is equally visually disconnected
 from Django's brand as the current admin skin. I'd recommend researching
 the various 3rd party attempts in implementing separate admin skins and
 find a common denominator.

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

Re: [Django] #24426: Admin actions panel is always hidden if show_full_result_count = False

2015-03-04 Thread Django

#24426: Admin actions panel is always hidden if show_full_result_count = False
-+-
 Reporter:  shultais |Owner:  timgraham
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.8beta1
 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 Tim Graham ):

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


Comment:

 In [changeset:"36a17be9f3cf6081f7e6f83fcfeae3d09ce8a72b"]:
 {{{
 #!CommitTicketReference repository=""
 revision="36a17be9f3cf6081f7e6f83fcfeae3d09ce8a72b"
 Fixed #24426 -- Displayed admin actions panel when
 show_full_result_count=False.
 }}}

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

Re: [Django] #19538: Remove __admin_media_prefix in admin templates (was: admin_media_prefix__ in admin templates)

2015-03-04 Thread Django

#19538: Remove __admin_media_prefix__ in admin templates
-+-
 Reporter:  andrew@… |Owner:  timgraham
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  admin S3 DateTime| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * version:  1.4 => master
 * owner:  garanko => timgraham
 * needs_docs:  0 => 1
 * has_patch:  0 => 1
 * type:  Bug => Cleanup/optimization


Comment:

 We can address this by moving image references to CSS and using relative
 paths.

 [https://github.com/django/django/pull/4236 Work in progress]

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

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

Re: [Django] #24430: wildcard matching and reversing of URLs

2015-03-04 Thread Django

#24430: wildcard matching and reversing of URLs
-+--
 Reporter:  eskhool  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core (URLs)  |  Version:  1.7
 Severity:  Normal   |   Resolution:  wontfix
 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 charettes):

 [https://docs.djangoproject.com/en/1.7/ref/contrib/admin/#multiple-admin-
 sites Multiple admin sites can already be deployed in same URLConf].

 You'd just have to create a namespaced admin site for each of you tenants
 or write an URLResolver that does it for you.

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

Re: [Django] #24446: ATOMIC_REQUESTS add extra queries if the view was already in a transaction

2015-03-04 Thread Django

#24446: ATOMIC_REQUESTS add extra queries if the view was already in a 
transaction
-+-
 Reporter:  diox |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 I discussed this with diox yesterday on IRC and suggested this patch which
 appears to fix the issue:

 {{{
 diff --git a/django/core/handlers/base.py b/django/core/handlers/base.py
 index e40eb2f..92ad394 100644
 --- a/django/core/handlers/base.py
 +++ b/django/core/handlers/base.py
 @@ -78,7 +78,7 @@ class BaseHandler(object):
  for db in connections.all():
  if (db.settings_dict['ATOMIC_REQUESTS']
  and db.alias not in non_atomic_requests):
 -view = transaction.atomic(using=db.alias)(view)
 +view = transaction.atomic(using=db.alias,
 savepoint=False)(view)
  return view

  def get_exception_response(self, request, resolver, status_code):
 }}}

 I think this change is for the better, however there's a potential for
 backwards incompatibility. If some developers went through the pain of
 adding 2 to all their `assertNumQueries`, forcing them to substract 2
 again isn't nice...

 That said, if I remember correctly, I had found a solution during the
 transaction refactor to avoid breaking `assertNumQueries`, so I'm not sure
 why diox is seeing this issue.

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

[Django] #24446: ATOMIC_REQUESTS add extra queries if the view was already in a transaction

2015-03-04 Thread Django

#24446: ATOMIC_REQUESTS add extra queries if the view was already in a
transaction
--+
Reporter: diox | Owner: nobody
Type: Bug | Status: new
Component: Database layer (models, ORM) |Version: master
Severity: Normal| Keywords:
Triage Stage: Unreviewed| Has patch: 0
Easy pickings: 0 | UI/UX: 0
--+
`ATOMIC_REQUESTS` documentation says it wraps the view in a transaction,
but since it actually only calls `atomic()`, it will actually use
savepoints if the view was already in a transaction when
`make_view_atomic()` is called.

This matters in tests, because `TestCase` opens a transaction by default.
With the old `TransactionMiddleware`, using a regular `TestCase` and
`assertNumQueries(0)` on views that did not make db queries of their own
worked, with `ATOMIC_REQUESTS` 2 queries are seen, breaking any tests
relying on this behavior.

Not sure whether to consider this a bug in the implementation or in the
documentation only. I certainly didn't expect all my `assertNumQueries()`
tests to fail when switching to `ATOMIC_REQUESTS`.

Attached is a patch demonstrating the issue.

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

Re: [Django] #24207: Change ogrinspect multi_geom default to True

2015-03-04 Thread Django

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

Comment:

I'm not convinced to force multi geometries by default. If you obtain
errors when importing data from a shapefile because of a missing multi
field, you can always improve your model and force the multi geometries in
a later time. And if you don't want to risk the potential errors, there is
the `multi_geom` parameter you can set yourself.

Feel free to add more arguments if you think I missed the point.

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

Re: [Django] #24426: Admin actions panel is always hidden if show_full_result_count = False

2015-03-04 Thread Django

#24426: Admin actions panel is always hidden if show_full_result_count = False
-+-
 Reporter:  shultais |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  1.8beta1
 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 charettes):

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

Re: [Django] #24433: Connection reset 'every time' when running inside Docker container

2015-03-04 Thread Django

#24433: Connection reset 'every time' when running inside Docker container
---+--
 Reporter:  zeonglow   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  HTTP handling  |  Version:  1.7
 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 claudep):

 * resolution:  needsinfo => invalid


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

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

Re: [Django] #24426: Admin actions panel is always hidden if show_full_result_count = False

2015-03-04 Thread Django

#24426: Admin actions panel is always hidden if show_full_result_count = False
-+-
 Reporter:  shultais |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  1.8beta1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * owner:  nobody => timgraham
 * 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/066.c97f4d616fce1071b6f28be0df68bf60%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24430: wildcard matching and reversing of URLs

2015-03-04 Thread Django

Comment (by eskhool):

Sorry for the delay in responding to the queries:
Tim,
Here is the use case below:

For each window that is open with a particular admin, I want to use it for
a different tenant of a multiple tenant (SAAS) site.

eg. SAAS_TENTANT//

This URL setup allows me to filter out the appropriate rows for the admin
to show for a particular SAAS for a particular tab

Charettes,
It can't be solved with a named wildcard group because the existing admin
does not provide any hooks for extending the same, short of overriding
every single admin view function individually and adding logic in each

Please review in light of the above use case. I would like to see a clean
way of doing this way as it will likely improve on the DRY and reusability
of code

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

Re: [Django] #19527: bulk_create() can set the primary key

2015-03-04 Thread Django

#19527: bulk_create() can set the primary key
-+-
 Reporter:  Tuttle   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by brillgen):

 * cc: dev@… (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/064.33cc68d78bd7cf573e77cd2159a6571f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24435: Removing blank=True, null=True from ManyToMany field causes data deletion in migration

2015-03-04 Thread Django

#24435: Removing blank=True, null=True from ManyToMany field causes data 
deletion
in migration
-+-
 Reporter:  marktranchant|Owner:  MarkusH
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.8beta1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  m2m migrations   | Triage Stage:  Ready for
  deletion blank null|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Markus Holtermann ):

 In [changeset:"bff446c205e0c4d436a5147906397ab7534343f3"]:
 {{{
 #!CommitTicketReference repository=""
 revision="bff446c205e0c4d436a5147906397ab7534343f3"
 [1.8.x] Fixed #24435 -- Prevented m2m field removal and addition in
 migrations when changing blank

 Thanks Mark Tranchant for the report and Tim Graham for the test and
 review.

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

Re: [Django] #24435: Removing blank=True, null=True from ManyToMany field causes data deletion in migration

2015-03-04 Thread Django

#24435: Removing blank=True, null=True from ManyToMany field causes data 
deletion
in migration
-+-
 Reporter:  marktranchant|Owner:  MarkusH
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.8beta1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  m2m migrations   | Triage Stage:  Ready for
  deletion blank null|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Markus Holtermann ):

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


Comment:

 In [changeset:"a9e29fae105d1ddd4e0ac2059cbe62b0ee348bc8"]:
 {{{
 #!CommitTicketReference repository=""
 revision="a9e29fae105d1ddd4e0ac2059cbe62b0ee348bc8"
 Fixed #24435 -- Prevented m2m field removal and addition in migrations
 when changing blank

 Thanks Mark Tranchant for the report an Tim Graham for the test and
 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/071.f7659ac1efbd7da370786ce9c95a30a1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24203: Optimisation: adding multiple fields to same model should attempt to run single ALTER TABLE statement

2015-03-04 Thread Django

#24203: Optimisation: adding multiple fields to same model should attempt to run
single ALTER TABLE statement
-+-
 Reporter:  peterlauri   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  migration| Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by peterlauri):

 Replying to [comment:2 timgraham]:
 > Could you give some performance numbers for comparison?

 I prepped a DB with some fields and 500k rows. The alter table statements
 as in my original description executed each in few milliseconds. No
 significant improvement to execute them in a single statement.

 {{{
 ballongen=# select count(*) from testtable;
  count
 
  50
 (1 row)

 Time: 34.261 ms
 ballongen=# ALTER TABLE "testtable" ADD COLUMN "field2" varchar(100) NULL;
 ALTER TABLE
 Time: 56.649 ms
 ballongen=# ALTER TABLE "testtable" ALTER COLUMN "field2" DROP DEFAULT;
 ALTER TABLE
 Time: 2.563 ms
 ballongen=# ALTER TABLE "testtable" ADD COLUMN "field3" varchar(100) NULL;
 ALTER TABLE
 Time: 1.165 ms
 ballongen=# ALTER TABLE "testtable" ALTER COLUMN "field3" DROP DEFAULT;
 ALTER TABLE
 Time: 0.240 ms
 }}}

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

Re: [Django] #24203: Optimisation: adding multiple fields to same model should attempt to run single ALTER TABLE statement

2015-03-04 Thread Django

#24203: Optimisation: adding multiple fields to same model should attempt to run
single ALTER TABLE statement
-+-
 Reporter:  peterlauri   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  migration| Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by peterlauri):

 Replying to [comment:2 timgraham]:
 > Could you give some performance numbers for comparison?

 This is not from production, it contains ~500k rows. I will try it out on
 PG as well, just need to prep some data.

 {{{
 mysql> select count(*) from thetable;
 +--+
 | count(*) |
 +--+
 |   489484 |
 +--+
 1 row in set (0.07 sec)

 mysql> ALTER TABLE thetable ADD COLUMN field2 varchar(100) NULL;
 Query OK, 489484 rows affected (2 min 29.05 sec)
 Records: 489484  Duplicates: 0  Warnings: 0

 mysql> ALTER TABLE thetable ADD COLUMN field3 varchar(100) NULL;
 Query OK, 489484 rows affected (2 min 10.82 sec)
 Records: 489484  Duplicates: 0  Warnings: 0

 mysql> ALTER TABLE thetable ADD COLUMN field4 varchar(100) NULL, ADD
 COLUMN field5 varchar(100) NULL;
 Query OK, 489484 rows affected (2 min 24.92 sec)
 Records: 489484  Duplicates: 0  Warnings: 0

 mysql>
 }}}

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

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

Re: [Django] #24435: Removing blank=True, null=True from ManyToMany field causes data deletion in migration

2015-03-04 Thread Django

#24435: Removing blank=True, null=True from ManyToMany field causes data 
deletion
in migration
-+-
 Reporter:  marktranchant|Owner:  MarkusH
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.8beta1
 Severity:  Release blocker  |   Resolution:
 Keywords:  m2m migrations   | Triage Stage:  Ready for
  deletion blank null|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #24433: Connection reset 'every time' when running inside Docker container

2015-03-04 Thread Django

#24433: Connection reset 'every time' when running inside Docker container
---+--
Reporter: zeonglow |Owner: nobody
Type: Uncategorized | Status: closed
Component: HTTP handling | Version: 1.7
Severity: Normal | Resolution: needsinfo
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 zeonglow):

* type: Bug => Uncategorized

Comment:

Hi Tim, yes you are correct, this in not a Django problem. I'l put the
answer here because I'm sure it will help someone ;-)

If you run the following
'''
python manage.py runserver'''

Django runs the development server on the localhost interface and port
8000, which is fine in most cases but with Docker, if you want to access
'anything' from outside a container it must listen on the faux eth0
interface, ( which is what the Docker documentation refers to as the
'bridge' interface)

In short
'''
python manage.py runserver 0.0.0.0:8000'''

Works as expected.

The reverse example

'''python -m 'http.server' --bind localhost 8000'''
''Serving HTTP on 127.0.0.1 port 8000 ...
''
Will now produce the 'connection resets' from outside the container.

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

Re: [Django] #24203: Optimisation: adding multiple fields to same model should attempt to run single ALTER TABLE statement

2015-03-04 Thread Django

Comment (by simonpercivall):

Replying to [comment:2 timgraham]:
> Could you give some performance numbers for comparison?

I can give performance numbers for a MySQL installation.

Doing an ALTER TABLE on a table with 120 columns and containing approx.
20M rows takes 2–3 hours. Combining several ALTER TABLES into one takes no
longer time.

The simple math here is that three Django migrations would take 6–9 hours,
whereas the combined version would take 2–3 hours.

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

Re: [Django] #24435: Removing blank=True, null=True from ManyToMany field causes data deletion in migration

2015-03-04 Thread Django

#24435: Removing blank=True, null=True from ManyToMany field causes data 
deletion
in migration
-+-
 Reporter:  marktranchant|Owner:  MarkusH
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.8beta1
 Severity:  Release blocker  |   Resolution:
 Keywords:  m2m migrations   | Triage Stage:  Accepted
  deletion blank null|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by MarkusH):

 * has_patch:  0 => 1


Comment:

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

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

Re: [Django] #24435: Removing blank=True, null=True from ManyToMany field causes data deletion in migration

2015-03-04 Thread Django

#24435: Removing blank=True, null=True from ManyToMany field causes data 
deletion
in migration
-+-
 Reporter:  marktranchant|Owner:  MarkusH
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.8beta1
 Severity:  Release blocker  |   Resolution:
 Keywords:  m2m migrations   | Triage Stage:  Accepted
  deletion blank null|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by MarkusH):

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


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

37 matches

Mail list logo