date:20150626

Re: [Django] #23422: Cannot add Permission to Group in data migration

2015-06-26 Thread Django

#23422: Cannot add Permission to Group in data migration
+--
 Reporter:  tjwalch |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  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 frnhr):

 The solution jwhitlock proposes with calling `create_permissions` from
 migration fixed one of my problematic migration, but not another. The
 other migration is calling `loaddata` command to do a one-time fixture
 import, and it was failing because required `ContentType` objects haven't
 been created. So it seems to be another face of the same problem.

 Here is a more dirty workaround until an official solution becomes
 available. I think it has better changes of fixing the problem in case
 solution with `create_permissions` fails:

 {{{
 if ContentType.objects.filter(**whats_needed_for_this_migration).count() <
 1:
 print("Running another migrate command from migration to create
 ContentType objects:")
 call_command('migrate', 'users', '0002')  # this should cite migration
 from the same app, just prior to this one
 print("Finished with the migrate command.")
 }}}

 I'm guessing the only thing really needed from the `migrate` management
 command in this situation is:

 {{{
 emit_post_migrate_signal(created_models, self.verbosity, self.interactive,
 connection.alias)
 }}}

 but not sure how to populate the arguments.

 I have no idea if using `call_command("migrate")` from a migration (of all
 places...) can be problematic, but in my particular case there don't seem
 to be any problems.

 The lengths we have to go to... Please **willfix** this.

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

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

Re: [Django] #25030: The /admin/login/ should observe external authentication even when it appears in POST

2015-06-26 Thread Django

Comment (by adelton):

Replying to [comment:2 claudep]:
> Regarding the current test failure for the patch, you are right about
ticket #19327 not being an issue any more with the new design.

Thanks for the confirmation.

> However, your patch is still slightly changing the "overriden-login"
behavior. Currently if I have two windows/tabs with a login form and I try
to login with two different users, the second POST will log the second
user which becomes then the current session user. With your patch, the
second POST will redirect to admin index while the first user is still the
current session user (already logged-in behavior). I understand that this
is an edge use case, as normally users logout before logging in as a
different user.

I understand the problem. However, checking the situation you describe
(open two tabs with unauthenticated /admin/login/, get two forms, submit
the first, submit the second with different username), I get

{{{
Forbidden (403)
CSRF verification failed. Request aborted.
}}}

So it looks like lately this scenario is not really possible, at least
with the django.middleware.csrf.CsrfViewMiddleware which seems enabled by
default.

I wonder if we have any way to figure out that the user was just
authenticated (their session marked as authenticated) in the current
request, presumably by some middlerware, to distinguish from the situation
when we piggybacked on some other long-running session.

> Your current proposal is only addressing the admin login use case, isn't
it? I'd be in favor of solving it directly in contrib.auth so every login
would benefit from it.

Yes, I only looked at admin. I will need to dig deeper into contrib.auth
to understand the interactions there.

> We might find a way to short-circuit the contrib.auth login view when
request.user is already authenticated and user.backend point to
RemoteUserBackend or a subclass. Thoughts?

That would certainly allow us to target the use case that I have in mind
most precisely. But I'm afraid that it might break the logic separation,
if we started to poke into users' backends directly -- it feels like
something that the application should not really care about.

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

Re: [Django] #24964: Infinite migrations with empty help_text via ugettext_lazy

2015-06-26 Thread Django

#24964: Infinite migrations with empty help_text via ugettext_lazy
-+-
 Reporter:  gimbo|Owner:  coldmind
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.8
 Severity:  Release blocker  |   Resolution:
 Keywords:  migrations,  | Triage Stage:  Accepted
  internationalisation   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by carljm):

 Replying to [comment:9 claudep]:
 > Do we have at least a use case for `help_text=_('')`?

 I don't, but this strikes me as a bug that deserves fixing even with no
 good use case for that. You should have to work harder than this to
 trigger infinite migrations...

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

Re: [Django] #25032: When /admin/login/ is accessed directly, there is 302 /admin/login/ after POST, and only then 302 /admin/

2015-06-26 Thread Django

#25032: When /admin/login/ is accessed directly, there is 302 /admin/login/ 
after
POST, and only then 302 /admin/
---+--
 Reporter:  adelton|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  contrib.admin  |  Version:  master
 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 adelton):

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


Comment:

 Filed https://github.com/django/django/pull/4927 to use the same default
 redirect target as the authenticated GET access.

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

[Django] #25032: When /admin/login/ is accessed directly, there is 302 /admin/login/ after POST, and only then 302 /admin/

2015-06-26 Thread Django

#25032: When /admin/login/ is accessed directly, there is 302 /admin/login/ 
after
POST, and only then 302 /admin/
---+
 Reporter:  adelton|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  contrib.admin  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 While investigating the behaviour for
 https://code.djangoproject.com/ticket/25030 in more detail, I've noticed
 that when I access (unauthenticated, via GET) /admin/login/ directly, the
 access_log shows

 {{{
 GET /admin/login/ HTTP/1.1" 200 1716
 POST /admin/login/ HTTP/1.1" 302 -
 GET /admin/login/ HTTP/1.1" 302 -
 GET /admin/ HTTP/1.1" 200 2826
 }}}

 The result of the form submission (the POST) is redirect to /admin/login/
 again. It seems to be caused by

 {{{
 if (REDIRECT_FIELD_NAME not in request.GET and
 REDIRECT_FIELD_NAME not in request.POST):
 context[REDIRECT_FIELD_NAME] = request.get_full_path()
 }}}

 When REDIRECT_FIELD_NAME is missing, why is the redirect going to
 /admin/login/ again? Wouldn't /admin/ be a better target?

 Of course, the

 {{{
 if request.method == 'GET' and self.has_permission(request):
 # Already logged-in, redirect to admin index
 index_path = reverse('admin:index', current_app=self.name)
 return HttpResponseRedirect(index_path)
 }}}

 will eventually throw it back to /admin/.

 This might seem like nitpicking but figuring out correct intended
 behaviour seems essential when I'm attempting to make changes to it to
 better support external authentication.

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

Re: [Django] #24964: Infinite migrations with empty help_text via ugettext_lazy

2015-06-26 Thread Django

#24964: Infinite migrations with empty help_text via ugettext_lazy
-+-
 Reporter:  gimbo|Owner:  coldmind
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.8
 Severity:  Release blocker  |   Resolution:
 Keywords:  migrations,  | Triage Stage:  Accepted
  internationalisation   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by claudep):

 Do we have at least a use case for `help_text=_('')`?

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

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

Re: [Django] #25029: When external authentication via REMOTE_USER is only configured on /admin/login/, the authentication does not persist

2015-06-26 Thread Django

#25029: When external authentication via REMOTE_USER is only configured on
/admin/login/, the authentication does not persist
--+
 Reporter:  adelton   |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by claudep):

 * needs_docs:  0 => 1
 * type:  Uncategorized => New feature
 * 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/065.8be033e6a21561d4ed16298a342d0f4a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25029: When external authentication via REMOTE_USER is only configured on /admin/login/, the authentication does not persist

2015-06-26 Thread Django

#25029: When external authentication via REMOTE_USER is only configured on
/admin/login/, the authentication does not persist
---+--
 Reporter:  adelton|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  contrib.auth   |  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
---+--

Comment (by adelton):

 I've updated the pull request to use the class name
 `PersistentRemoteUserMiddleware` as proposed during 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/065.2da397e5245718aa99849ca9ea666a9a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25030: The /admin/login/ should observe external authentication even when it appears in POST

2015-06-26 Thread Django

* component: contrib.admin => contrib.auth
* needs_better_patch: 0 => 1
* type: Uncategorized => New feature
* stage: Unreviewed => Accepted

Comment:

Regarding the current test failure for the patch, you are right about
ticket #19327 not being an issue any more with the new design.

However, your patch is still slightly changing the "overriden-login"
behavior. Currently if I have two windows/tabs with a login form and I try
to login with two different users, the second POST will log the second
user which becomes then the current session user. With your patch, the
second POST will redirect to admin index while the first user is still the
current session user (already logged-in behavior). I understand that this
is an edge use case, as normally users logout before logging in as a
different user.

Your current proposal is only addressing the admin login use case, isn't
it? I'd be in favor of solving it directly in contrib.auth so every login
would benefit from it. We might find a way to short-circuit the
contrib.auth login view when request.user is already authenticated and
user.backend point to RemoteUserBackend or a subclass. Thoughts?

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

Re: [Django] #23422: Cannot add Permission to Group in data migration

2015-06-26 Thread Django

#23422: Cannot add Permission to Group in data migration
+--
 Reporter:  tjwalch |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  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
+--
Changes (by frnhr):

 * cc: frnhr (added)


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

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

Re: [Django] #24100: Make `post_migrate` dispatch the migration plan.

2015-06-26 Thread Django

#24100: Make `post_migrate` dispatch the migration plan.
-+
 Reporter:  charettes|Owner:  MarkusH
 Type:  New feature  |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by frnhr):

 * cc: frnhr (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/067.825d0ec4330eb2b30db58f10c6ee3baf%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25029: When external authentication via REMOTE_USER is only configured on /admin/login/, the authentication does not persist

2015-06-26 Thread Django

#25029: When external authentication via REMOTE_USER is only configured on
/admin/login/, the authentication does not persist
---+--
 Reporter:  adelton|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  contrib.auth   |  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
---+--

Comment (by aaugustin):

 See #17869 for the opposite request.

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

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

[Django] #25031: unordered_list template filter fails for certain sequences

2015-06-26 Thread Django

#25031: unordered_list template filter fails for certain sequences
--+
 Reporter:  noamkush  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Template  |Version:  1.8
  system  |
 Severity:  Normal|   Keywords:  unordered_list template filter
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+
 unordered_list consumes it's input by pairs. When given a sequence that
 contains at an even position two strings and then a list (such as {{{['a',
 'a', ['b']]}}}), it will consume both strings and treat the list as an
 item on it's own, and not as a sublist of the second string.

 The result:
 {{{
 >>> from django.template import defaultfilters
 >>> print str(defaultfilters.unordered_list(['a', 'a', ['b']]))
 a
 a
 [b]
 }}}

 See pull request with a test and a fix:
 https://github.com/django/django/pull/4917

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

Re: [Django] #25029: When external authentication via REMOTE_USER is only configured on /admin/login/, the authentication does not persist

2015-06-26 Thread Django

#25029: When external authentication via REMOTE_USER is only configured on
/admin/login/, the authentication does not persist
---+--
 Reporter:  adelton|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  contrib.auth   |  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
---+--

Comment (by carljm):

 Ok, I'm convinced that this new variant is at least as useful as
 `RemoteUserMiddleware` itself. I won't stand in the way. Thanks for the
 expanded rationale.

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

Re: [Django] #25029: When external authentication via REMOTE_USER is only configured on /admin/login/, the authentication does not persist

2015-06-26 Thread Django

#25029: When external authentication via REMOTE_USER is only configured on
/admin/login/, the authentication does not persist
---+--
Reporter: adelton|Owner: nobody
Type: Uncategorized | Status: new
Component: contrib.auth | 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
---+--

Comment (by adelton):

Replying to [comment:2 carljm]:
> Is there any compelling benefit to having this in core Django rather
than an external library?

The benefit is increased number of deployments of **existing**
applications that can be done by changing one line in MIDDLEWARE_CLASSES
in settings.py. In many cases the person deploying that application which
needs to consume external authentication is not a programmer and dealing
with extra code is a blocker. Having the option come directly with Django
seems more straightforward. From maintenance point of view, the class
touches some internals of Django that it seems best to have it with the
rest of the `RemoteUserMiddleware` code so that should the internals
change, people are not faced with the task of getting correct version of
the external library.

Normally I'd say that `RemoteUserMiddleware` should not even insist on
seeing the REMOTE_USER filled upon every request but I guess changing the
current behaviour might be disruptive, that's why I'm proposing a way for
admin to be explicit with their choice of behaviour.

The traditional model of REMOTE_USER being produced primarily by setups
with HTTP Basic Auth which keeps sending the credentials with every
request and thus the username available with every request is no longer
there as virtually noone uses Basic Authentication, while external
authentication in frontend HTTP server can bring benefits especially in
large organizations when the Apache modules are used for cross-realm
authentication or identity federation. The typical use-case is then to
override or extend one (logon) URL. We have a writeup about the approach
at http://www.freeipa.org/page/Web_App_Authentication.

Another benefit for Django as a project is that it would make it much
easier to use Django in demos of external authentications, be it Kerberos,
SAML, or other.

> I'm not convinced the need is frequent enough to have it in core Django.
(Even `RemoteUserMiddleware` itself is on the edge, IMO).

It's not in core Django, it's in `django/contrib/auth`. I thought the
contrib in the name makes it a good place to live, especially for
"integration" code like this.

You might not see many `RemoteUserMiddleware` deployments exactly for the
reason that with other authentication mechanisms than Basic Auth, it's
currently not particularly useful.

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

Re: [Django] #24721: Introduce something similar to mail.outbox for messages

2015-06-26 Thread Django

#24721: Introduce something similar to mail.outbox for messages
--+
 Reporter:  mjtamlyn  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.messages  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by mjtamlyn):

 Proof of concept at https://github.com/django/django/pull/4926

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

Re: [Django] #25028: annotation with Q object duplicates results

2015-06-26 Thread Django

Comment (by akaariai):

This is a bit different from #10060, as there is no aggregation going on
here. The problem is that a single user has multiple groups, and you'll
get a different annotation for each of the groups.

You'll likely get the correct result if you add
`filter(Q(groups__name='group1')|Q(groups__isnull=True))` *before* the
annotate() call. This will work as the user can have at most one group
named group1.

I think there would be room for adding a generic query operator for asking
"annotate True to users which have at least (or at most) N groups matching
condition X". Your case is "at least 1 group named 'group1'", with the
extra constraint that group's name is unique. In the more general cases
answering this question requires aggregation. Notably you could also solve
your problem by conditional aggregation where you count all groups that
are named 'group1', and then annotate True if result is greater or equal
to 1.

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

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

Re: [Django] #25030: The /admin/login/ should observe external authentication even when it appears in POST

2015-06-26 Thread Django

#25030: The /admin/login/ should observe external authentication even when it
appears in POST
---+--
 Reporter:  adelton|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  contrib.admin  |  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 adelton):

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


Comment:

 Proposed patch at https://github.com/django/django/pull/4925.

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

Re: [Django] #25029: When external authentication via REMOTE_USER is only configured on /admin/login/, the authentication does not persist

2015-06-26 Thread Django

#25029: When external authentication via REMOTE_USER is only configured on
/admin/login/, the authentication does not persist
---+--
 Reporter:  adelton|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  contrib.auth   |  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
---+--

Comment (by carljm):

 Is there any compelling benefit to having this in core Django rather than
 an external library?

 I'm not convinced the need is frequent enough to have it in core Django.
 (Even `RemoteUserMiddleware` itself is on the edge, IMO).

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

[Django] #25030: The /admin/login/ should observe external authentication even when it appears in POST

2015-06-26 Thread Django

#25030: The /admin/login/ should observe external authentication even when it
appears in POST
---+
 Reporter:  adelton|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  contrib.admin  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Apache module mod_intercept_form_submit
 (http://www.adelton.com/apache/mod_intercept_form_submit/) allows PAM
 authentication to be run by Apache when application's native logon form is
 submitted. The module attempts the PAM authentication and sets
 {{{r->user}}} / REMOTE_USER accordingly. The use case is described in more
 detail at
 http://www.freeipa.org/page/Web_App_Authentication#Login_form_using_FreeIPA
 and
 
http://www.freeipa.org/page/Web_App_Authentication/Example_setup#External_identities_for_login_form.

 However, Django's /admin/login/ implementation has check

 {{{
 if request.method == 'GET' and self.has_permission(request):
 }}}

 in its {{{login}}} method. So even if I have Apache configured with

 {{{
 LoadModule authnz_pam_module modules/mod_authnz_pam.so
 LoadModule intercept_form_submit_module
 modules/mod_intercept_form_submit.so
 
 InterceptFormPAMService django-admin
 InterceptFormLogin username
 InterceptFormPassword password
 
 }}}

 and in access_log I see the admin user authenticated by the module, since
 it happened during POST request, /admin/login/ ignores the fact that
 {{{self.has_permission(request)}}} returns true and prints error message
 "Please enter the correct username and password for a staff account. Note
 that both fields may be case-sensitive." However, the session based on
 REMOTE_USER has actually been created so if you just repeat the same
 request (http://www.example.com/admin/login/?next=/admin/) with GET by
 hitting Ctrl+L and Enter, you will get to /admin/ without issues.

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

Re: [Django] #25029: When external authentication via REMOTE_USER is only configured on /admin/login/, the authentication does not persist

2015-06-26 Thread Django

#25029: When external authentication via REMOTE_USER is only configured on
/admin/login/, the authentication does not persist
---+--
 Reporter:  adelton|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  contrib.auth   |  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 adelton):

 * cc: adelton (added)
 * needs_docs:   => 0
 * has_patch:  0 => 1
 * needs_tests:   => 0
 * needs_better_patch:   => 0


Comment:

 Proposed patch https://github.com/django/django/pull/4924.

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

[Django] #25029: When external authentication via REMOTE_USER is only configured on /admin/login/, the authentication does not persist

2015-06-26 Thread Django

#25029: When external authentication via REMOTE_USER is only configured on
/admin/login/, the authentication does not persist
---+
Reporter: adelton| Owner: nobody
Type: Uncategorized | Status: new
Component: contrib.auth |Version: master
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
---+
The ticket #17869 made sure that if the REMOTE_USER header is not present,
user is logged out in Django as well. Ticket #23066 moved the logic to
different method but the semantic stayed the same.

However, for certain external authentication mechanisms, it makes sense
that the frontend server (Apache) is configured to only authenticate
single URL, like /admin/login/. For example with Kerberos, we do not want
the negotiate to happen upon every request -- we want Django to accept the
external authentication, create the session, and then use that session
until the user explicitly log out.

I assume changing the current behaviour of RemoteUserMiddleware is not
acceptable so I'm proposing new middleware, OptionalRemoteUserMiddleware,
to allow the REMOTE_USER to be only present once.

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

Re: [Django] #25017: settings.DISALLOWED_USER_AGENTS should raise PermissionDenied

2015-06-26 Thread Django

#25017: settings.DISALLOWED_USER_AGENTS should raise PermissionDenied
-+-
 Reporter:  fschiettecatte   |Owner:
 Type:   |  SujaySKumar
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  DISALLOWED_USER_AGENTS,|
  PermissionDenied   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:  0 => 1


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

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

Re: [Django] #25028: annotation with Q object duplicates results

2015-06-26 Thread Django

#25028: annotation with Q object duplicates results
---+--
 Reporter:  karyon |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Uncategorized  |  Version:  1.8
 Severity:  Normal |   Resolution:  duplicate
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by timgraham):

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


Comment:

 Duplicate of #10060

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

Re: [Django] #25026: Should QueryDict accept "html json forms"?

2015-06-26 Thread Django

#25026: Should QueryDict accept "html json forms"?
---+--
 Reporter:  zauddelig  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  Version:  master
 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 timgraham):

 It may be a bit premature to implement functionality described in a
 working draft document. Can you provide any information about whether
 other projects are implementing its functionality?

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

Re: [Django] #24958: Inline admins broken with UUID parent key and AutoField child key

2015-06-26 Thread Django

#24958: Inline admins broken with UUID parent key and AutoField child key
-+
 Reporter:  jhoos|Owner:  jhoos
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.8
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+

Comment (by Tim Graham ):

 In [changeset:"429680146304c44e92ecff655280bc464121f769" 42968014]:
 {{{
 #!CommitTicketReference repository=""
 revision="429680146304c44e92ecff655280bc464121f769"
 [1.8.x] Fixed #24958 -- Fixed inline forms using UUID-PK parents with
 auto-PK children.

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

Re: [Django] #25016: The related_name of ForeignKey cannot be Unicode name after Django 1.8

2015-06-26 Thread Django

#25016: The related_name of ForeignKey cannot be Unicode name after Django 1.8
-+-
 Reporter:  sih4sing5hong5   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"a97e50c5e6afe0ce2a8fb2ca27c88e57611b0053" a97e50c5]:
 {{{
 #!CommitTicketReference repository=""
 revision="a97e50c5e6afe0ce2a8fb2ca27c88e57611b0053"
 [1.8.x] Fixed #25016 -- Reallowed non-ASCII values for
 ForeignKey.related_name on Python 3.

 Backport of d3e12c901777697b7bf08b25e2dd46f0b951db8c from master
 }}}

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

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

Re: [Django] #24958: Inline admins broken with UUID parent key and AutoField child key

2015-06-26 Thread Django

#24958: Inline admins broken with UUID parent key and AutoField child key
-+
 Reporter:  jhoos|Owner:  jhoos
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.8
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"a50b66da30320887c23c73927f6b2ab41e0301bf" a50b66d]:
 {{{
 #!CommitTicketReference repository=""
 revision="a50b66da30320887c23c73927f6b2ab41e0301bf"
 Fixed #24958 -- Fixed inline forms using UUID-PK parents with auto-PK
 children.
 }}}

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

Re: [Django] #24840: Add Warp and Transform functionality for GDALRasters

2015-06-26 Thread Django

#24840: Add Warp and Transform functionality for GDALRasters
-+
 Reporter:  yellowcap|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  GIS  |  Version:  1.8
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  raster gdal gis  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by claudep):

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


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

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

Re: [Django] #24840: Add Warp and Transform functionality for GDALRasters

2015-06-26 Thread Django

#24840: Add Warp and Transform functionality for GDALRasters
-+
 Reporter:  yellowcap|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  GIS  |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  raster gdal gis  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Claude Paroz ):

 In [changeset:"b647ccfa673890d4ee30a29bb759a19e4f1a67dc" b647ccfa]:
 {{{
 #!CommitTicketReference repository=""
 revision="b647ccfa673890d4ee30a29bb759a19e4f1a67dc"
 Refs #24840 -- Added skip flag to raster transform test for GDAL<1.8.1.

 Thanks to Simon Charette for the report.
 }}}

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

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

Re: [Django] #25016: The related_name of ForeignKey cannot be Unicode name after Django 1.8

2015-06-26 Thread Django

#25016: The related_name of ForeignKey cannot be Unicode name after Django 1.8
-+-
 Reporter:  sih4sing5hong5   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"d3e12c901777697b7bf08b25e2dd46f0b951db8c" d3e12c9]:
 {{{
 #!CommitTicketReference repository=""
 revision="d3e12c901777697b7bf08b25e2dd46f0b951db8c"
 Fixed #25016 -- Reallowed non-ASCII values for ForeignKey.related_name on
 Python 3.
 }}}

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

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

Re: [Django] #20562: Docs: How to use django ORM with multiprocessing

2015-06-26 Thread Django

#20562: Docs: How to use django ORM with multiprocessing
--+
 Reporter:  guettli   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.5
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by guettli):

 I created this ticket two years ago. I think a guideline is enough here.

 I resolved my issues by checking that no ORM code gets executed before the
 multiprocessing module spawns the workers.

 In other words:

  1. start the workers via multiprocessing.
  2. connect to DB.

 If you have N workers, you need N connections to the database.

 I think no change to the django code base is necessary. Just docs.

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

Re: [Django] #25025: Django migration (>=1.7) like index

2015-06-26 Thread Django

#25025: Django migration (>=1.7) like index
---+--
 Reporter:  TZanke |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.7
 Severity:  Normal |   Resolution:  duplicate
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by timgraham):

 * resolution:  needsinfo => duplicate


Comment:

 Duplicate of #24507 and #24088. See also
 [https://groups.google.com/d/topic/django-
 developers/H2QFcQYsbo8/discussion discussion on django-developers].

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

Re: [Django] #25027: two relations on the same model with same related_name break the model

2015-06-26 Thread Django

#25027: two relations on the same model with same related_name break the model
-+-
 Reporter:  karyon   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * status:  new => closed
 * resolution:   => duplicate
 * component:  Uncategorized => Database layer (models, ORM)


Comment:

 Duplicate of #24505 (currently fixed on master, but not 1.8).

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

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

Re: [Django] #24507: Add the possibility to create only one index on CharField

2015-06-26 Thread Django

#24507: Add the possibility to create only one index on CharField
-+-
 Reporter:  rodo |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  index| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 [https://groups.google.com/d/topic/django-
 developers/H2QFcQYsbo8/discussion Discussion on django-developers].

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

[Django] #25028: annotation with Q object duplicates results

2015-06-26 Thread Django

#25028: annotation with Q object duplicates results
---+
 Reporter:  karyon |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.8
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 consider the following models:


 {{{
 class UserProfile(models.Model):
 pass

 class Group(models.Model):
 name = models.CharField(max_length=255)
 users = models.ManyToManyField(UserProfile, related_name='groups')
 }}}

 and the following test:
 {{{
 def test_annotation(self):
 group1 = Group.objects.create(name="group1")
 group2 = Group.objects.create(name="group2")
 user = UserProfile.objects.create()
 user.groups = [group1, group2]
 users =
 
UserProfile.objects.all().annotate(is_group1=ExpressionWrapper(Q(groups__name="group1"),
 output_field=BooleanField()))
 for u in users:
 print(u.is_group1)
 print(users.query)
 self.assertEqual(users.count(), 1)
 }}}

 this prints the following:

 {{{
 Creating test database for alias 'default'...
 1
 0
 SELECT "testapp_userprofile"."id", "testapp_group"."name" = group1 AS
 "is_group1" FROM "testapp_userprofile" LEFT OUTER JOIN
 "testapp_group_users" ON ( "testapp_userprofile"."id" =
 "testapp_group_users"."userprofile_id") LEFT OUTER JOIN "testapp_group" ON
 ( "testapp_group_users"."group_id" = "testapp_group"."id" )
 F
 
 AssertionError: 2 != 1
 }}}


 the annotation is supposed to add a bool to the user indicating whether
 that user is part of some group or not. i haven't found an easier way to
 do it. this worked for us until we had a user that was in two groups at
 the same time.

 for some reason the annotation with the Q object causes the user the
 appear two times in the result, once with is_group1==True, once with
 is_group1==False. if i make the user have only one group, the test
 succeeds.

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

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

Re: [Django] #25027: two relations on the same model with same related_name break the model

2015-06-26 Thread Django

#25027: two relations on the same model with same related_name break the model
---+--
 Reporter:  karyon |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  1.8
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Description changed by karyon:

Old description:

> consider the following models:
> {{{
> class UserProfile(models.Model):
> pass
>
> class Course(models.Model):
> participants = models.ManyToManyField(UserProfile,
> related_name='foo')
>
> class Document(models.Model):
> last_modified_user = models.ForeignKey(UserProfile,
> related_name='foo')
> }}}
>
> and the following query:
> {{{
> >>> str(Course.objects.first().participants.all().query)
> 'SELECT "testapp_userprofile"."id" FROM "testapp_userprofile" INNER JOIN
> "testapp_document" ON ( "testapp_userprofile"."id" =
> "testapp_document"."last_modified_user_id" ) WHERE
> "testapp_document"."id" = 1'
> }}}
>
> the join doesn't make any sense to me. it makes both assertions in the
> following test fail:
>
> {{{
> def test_related_name(self):
> user = UserProfile.objects.create()
> course = Course.objects.create()
> course.participants = UserProfile.objects.all()
> self.assertEqual(course.participants.count(), 1)
> self.assertEqual(list(course.participants.all()), [user])
> }}}
>

> changing the related name in one of the models to something else fixes
> this.
>
> i would have expected to get some warning that i'm using the same related
> name on the same model. especially i expected this to not break when i'm
> not even using the related name in the test.
>
> this also breaks when using '+' as related name. in this case, i would
> expect everything to just work.

New description:

 consider the following models:
 {{{
 class UserProfile(models.Model):
 pass

 class Course(models.Model):
 participants = models.ManyToManyField(UserProfile, related_name='+')

 class Document(models.Model):
 last_modified_user = models.ForeignKey(UserProfile, related_name='+')
 }}}

 and the following query:
 {{{
 >>> str(Course.objects.first().participants.all().query)
 'SELECT "testapp_userprofile"."id" FROM "testapp_userprofile" INNER JOIN
 "testapp_document" ON ( "testapp_userprofile"."id" =
 "testapp_document"."last_modified_user_id" ) WHERE "testapp_document"."id"
 = 1'
 }}}

 the join doesn't make any sense to me. it makes both assertions in the
 following test fail:

 {{{
 def test_related_name(self):
 user = UserProfile.objects.create()
 course = Course.objects.create()
 course.participants = UserProfile.objects.all()
 self.assertEqual(course.participants.count(), 1)
 self.assertEqual(list(course.participants.all()), [user])
 }}}


 changing the related name in one of the models to something else fixes
 this.

 if using a related name other than '+', the test still fails as before and
 the check command does not complain either, but at least makemigrations
 will spot the mistake.

--

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

Re: [Django] #25027: two relations on the same model with same related_name break the model

2015-06-26 Thread Django

#25027: two relations on the same model with same related_name break the model
---+--
 Reporter:  karyon |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  1.8
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by karyon):

 * cc: karyon (added)
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


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

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

[Django] #25027: two relations on the same model with same related_name break the model

2015-06-26 Thread Django

#25027: two relations on the same model with same related_name break the model
---+
 Reporter:  karyon |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.8
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 consider the following models:
 {{{
 class UserProfile(models.Model):
 pass

 class Course(models.Model):
 participants = models.ManyToManyField(UserProfile, related_name='foo')

 class Document(models.Model):
 last_modified_user = models.ForeignKey(UserProfile,
 related_name='foo')
 }}}

 and the following query:
 {{{
 >>> str(Course.objects.first().participants.all().query)
 'SELECT "testapp_userprofile"."id" FROM "testapp_userprofile" INNER JOIN
 "testapp_document" ON ( "testapp_userprofile"."id" =
 "testapp_document"."last_modified_user_id" ) WHERE "testapp_document"."id"
 = 1'
 }}}

 the join doesn't make any sense to me. it makes both assertions in the
 following test fail:

 {{{
 def test_related_name(self):
 user = UserProfile.objects.create()
 course = Course.objects.create()
 course.participants = UserProfile.objects.all()
 self.assertEqual(course.participants.count(), 1)
 self.assertEqual(list(course.participants.all()), [user])
 }}}


 changing the related name in one of the models to something else fixes
 this.

 i would have expected to get some warning that i'm using the same related
 name on the same model. especially i expected this to not break when i'm
 not even using the related name in the test.

 this also breaks when using '+' as related name. in this case, i would
 expect everything to just work.

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

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

Re: [Django] #25025: Django migration (>=1.7) like index

2015-06-26 Thread Django

#25025: Django migration (>=1.7) like index
---+--
 Reporter:  TZanke |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  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 claudep):

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


Comment:

 If you don't want an "automatic" index, why simply not specify db_index on
 the field? If I missed the point, please develop your use case a bit more.

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

Re: [Django] #24840: Add Warp and Transform functionality for GDALRasters

2015-06-26 Thread Django

#24840: Add Warp and Transform functionality for GDALRasters
-+
 Reporter:  yellowcap|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  GIS  |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  raster gdal gis  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by yellowcap):

 Ok I narrowed down the gdal version, the test works from 1.8.1 forward
 (tested versions using
 [https://gist.github.com/yellowcap/1836a10bf0e04ea3e5c2 this]).  Here is a
 patch for the version checker

 
https://github.com/geodesign/django/commit/effdc27c60d670a5d393127e0d0be572fe5ec8ae

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

Re: [Django] #20562: Docs: How to use django ORM with multiprocessing

2015-06-26 Thread Django

#20562: Docs: How to use django ORM with multiprocessing
--+
 Reporter:  guettli   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.5
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by aaugustin):

 OK, I'm out of my depth there. All I know if that, if multiple children
 attempt to use a connection established in the parent, you get timeouts,
 probably because packets are sent back to the parent.

 Is there something like a "pre-fork" signal that Django could react to?
 I'm not aware of such a thing.

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

Re: [Django] #25026: Should QueryDict accept "html json forms"?

2015-06-26 Thread Django

#25026: Should QueryDict accept "html json forms"?
---+--
 Reporter:  zauddelig  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  Version:  master
 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 zauddelig):

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


Old description:

> On 23 may 2014 W3C published this working draft:
> http://www.w3.org/TR/html-json-forms/
>
> I'm focusing the attention on this paragraph:
>
> >User agents that implement this specification will transmit JSON data
> from their forms whenever the form's enctype attribute is set to
> '''application/json'''. During the transition period, user agents that do
> not support this encoding will fall back to using '''application/x-www-
> form-urlencoded'''. '''This can be detected on the server side, and the
> conversion algorithm described in this specification can be used to
> convert such data to JSON'''.'
>
> Should Django QueryDict support this transition period and return data
> structures?
>
> Here are some examples on how QueryDict should behave following the
> working draft:
>

> {{{
> >>> QueryDict("a=1=2")  # classical behavior
> 
> >>> QueryDict("a[0]=1[1]=2")  # the new behavior
> 
> }}}

New description:

 On 23 may 2014 W3C published this working draft:
 http://www.w3.org/TR/html-json-forms/

 I'm focusing the attention on this paragraph:

 >User agents that implement this specification will transmit JSON data
 from their forms whenever the form's enctype attribute is set to
 '''application/json'''. During the transition period, user agents that do
 not support this encoding will fall back to using '''application/x-www-
 form-urlencoded'''. '''This can be detected on the server side, and the
 conversion algorithm described in this specification can be used to
 convert such data to JSON'''.'

 Should Django QueryDict support this transition period and return data
 structures?

 Here are some examples on how QueryDict should behave following the
 working draft:


 {{{
 >>> QueryDict("a=1=2")  # classical behavior
 
 >>> QueryDict("a[0]=1[1]=2")  # the new behavior
 
 >>> QueryDict("a[0]=1[1]=2")  # proposed to fix behavior
 

 }}}

--

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

[Django] #25026: Should QueryDict accept "html json forms"?

2015-06-26 Thread Django

#25026: Should QueryDict accept "html json forms"?
---+
 Reporter:  zauddelig  |  Owner:  nobody
 Type:  New feature| Status:  new
Component:  HTTP handling  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 On 23 may 2014 W3C published this working draft:
 http://www.w3.org/TR/html-json-forms/

 I'm focusing the attention on this paragraph:

 >User agents that implement this specification will transmit JSON data
 from their forms whenever the form's enctype attribute is set to
 '''application/json'''. During the transition period, user agents that do
 not support this encoding will fall back to using '''application/x-www-
 form-urlencoded'''. '''This can be detected on the server side, and the
 conversion algorithm described in this specification can be used to
 convert such data to JSON'''.'

 Should Django QueryDict support this transition period and return data
 structures?

 Here are some examples on how QueryDict should behave following the
 working draft:


 {{{
 >>> QueryDict("a=1=2")  # classical behavior
 
 >>> QueryDict("a[0]=1[1]=2")  # the new behavior
 
 }}}

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

[Django] #25025: Django migration (>=1.7) like index

2015-06-26 Thread Django

#25025: Django migration (>=1.7) like index
---+
 Reporter:  TZanke |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.7
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Django migration generates 'like' indexes for database text fields.

 For example:

 "auth_user_username_51b3b110094b8aae_like" btree (username
 varchar_pattern_ops)

 I would like to explicitly set indexes in database.

 Is it possible to disable like index generation with django migrations?

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

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

Re: [Django] #25021: Document differences between HStore values query with contains and standard __contains lookup

2015-06-26 Thread Django

#25021: Document differences between HStore values query with contains and 
standard
__contains lookup
-+-
 Reporter:  amagidow |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Documentation|  Version:  1.8
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  HStore, Postgresql,  | Triage Stage:  Accepted
  queries|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by akaariai):

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


Comment:

 The array field works as expected, the ArrayField overrides the contains
 lookup, see
 https://docs.djangoproject.com/en/1.8/ref/contrib/postgres/fields/#contains

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

Re: [Django] #20562: Docs: How to use django ORM with multiprocessing

2015-06-26 Thread Django

#20562: Docs: How to use django ORM with multiprocessing
--+
 Reporter:  guettli   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.5
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by MoritzS):

 Replying to [comment:8 aaugustin]:
 > This question isn't specific to Django. The general problem that you
 can't carry sockets across fork.

 fork() copies the whole file descriptor table to the child process, so
 sockets are definitely carried across to the child process.

 It's just that you have to explicitly and carefully handle the sockets to
 open and close them in the correct processes.
 And that's where Django and probably most of the db driver libraries fall
 short.

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

Re: [Django] #20562: Docs: How to use django ORM with multiprocessing

2015-06-26 Thread Django

Comment (by aaugustin):

Most users of the Django ORM use it from multiple processes, since most
production WSGI servers use multiple processes :-)

This question isn't specific to Django. The general problem that you can't
carry sockets across fork.

If your Django process has network connections to remote data stores and
you want to fork, you need to close these connections before forking.
(Usually, they're reopened automatically on the next access.)

In practice, applications servers fork before Django does anything, so
this issue only arises when you fork in a management command, typically
because you're trying to use `multiprocessing`.

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

48 matches

Mail list logo