Re: Database connection retry

2017-03-01 Thread Tim Graham
I don't know. Can you propose a patch so we can see what's involved? How 
would a "production" web server (nginx, apache, etc.) handle the issue?

I'm more interested in moving runserver toward using gunicorn [0] (Windows 
support seems the main blocker to proceeding there) than adding more 
features to our own webserver, although it's not clear if the fix would 
actually involve the webserver.

[0] https://code.djangoproject.com/ticket/21978

On Wednesday, March 1, 2017 at 6:52:48 PM UTC-5, is_null wrote:
>
> Sometimes it's not started because some modern orchestration tools such as 
> ansible-container and docker-compose (perhaps more) start everything at 
> once, and django might be faster than the db, or I have to fix something 
> with the db orchestration tool.
>
> I noted we might have the same issue with redis+channels (if I've not 
> waited long enough before taking action instead of waiting for channels to 
> retry). It seems like something reasonable to improve the development 
> experience with Django while keeping up with the orchestration tools 
> because I've heard about other users making tools in python on top of 
> docker-compose just to add the orchestration that their Django project 
> needed (I swear) already two years ago.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d2d72cc5-3b18-4d6e-bbed-833fdff02226%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Database connection retry

2017-03-01 Thread James Pic
Sometimes it's not started because some modern orchestration tools such as
ansible-container and docker-compose (perhaps more) start everything at
once, and django might be faster than the db, or I have to fix something
with the db orchestration tool.

I noted we might have the same issue with redis+channels (if I've not
waited long enough before taking action instead of waiting for channels to
retry). It seems like something reasonable to improve the development
experience with Django while keeping up with the orchestration tools
because I've heard about other users making tools in python on top of
docker-compose just to add the orchestration that their Django project
needed (I swear) already two years ago.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3Kae-iWpWD3ZNFRu_GF9M0601bg8%2BpBGPR229%2BxgHrSfZ%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Database connection retry

2017-03-01 Thread Tim Graham
Could you explain the use case a bit more? Why is your database failing on 
a regular basis?

On Wednesday, March 1, 2017 at 4:00:12 PM UTC-5, James Pic wrote:
>
> Hi all,
>
> It seems like runserver won't retry to connect to the database after a 
> failing connection. Once the db server is up, it looks like I have to 
> restart runserver manually.
>
> If this is correct, may I suggest that we make runserver retry connecting 
> to the database if it fails ?
>
> Thanks
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5015961b-21c4-4d1f-83b4-cb962fa2330b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Database connection retry

2017-03-01 Thread James Pic
Hi all,

It seems like runserver won't retry to connect to the database after a
failing connection. Once the db server is up, it looks like I have to
restart runserver manually.

If this is correct, may I suggest that we make runserver retry connecting
to the database if it fails ?

Thanks

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op19Q3nGUU1wCCsmdJbHhUvqEuaS-wNc9htAE1QXLQocsBw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Template handling of undefined variables

2017-03-01 Thread Luke Plant



On 01/03/17 01:53, Tim Martin wrote:


On Tuesday, 28 February 2017 13:39:21 UTC, Luke Plant wrote:


On 28/02/17 15:24, Marten Kenbeek wrote:

What about adding a filter |definedthat returns True if a
variable is defined, False otherwise? It may not solve any
problems when it's left implicit, but at least it allows users
the explicitly define the behaviour for non-existing template
variables, and it makes the intention of the template code
crystal clear. And of course it's fully backwards compatible. The
drawback is perhaps the resulting verbosity of if statements:

{% if user.role|defined and roles.staff|defined and user.role
== roles.staff %}
[sensitive information here]
{% endif %}



The only way to do it would be to hard code this filter into the
template engine, because otherwise the 'defined' filter runs too
late to know whether the variable is defined.  This is really
hacky and magic.



Is that true? In my patch, the undefined variable gets expanded into 
an UndefinedVariable sentinel object, which can be detected by the 
defined modifier, and can compare == to None (or not, if you wish). 
Other than the result of the 'is' operator, I think you can make this 
fully backward compatible if you choose. Whether or not this is 
desirable is another question, of course.


I was talking about with the current behaviour of template engine i.e. 
without changing how undefined variables are handled. For this to work 
as you proposed, you would have to be passing the UndefinedVariable 
object into these filters. Having checked out your branch, I can see 
that is what you are doing.


This is a really big backwards incompatibility, as far as I can see. It 
means that any filter may now get passed `UndefinedVariable` instead of 
being passed `None` or string_if_invalid. So for example, the following 
template behaves oppositely with your patch, if variable 'missing' is 
undefined:


{% if missing|yesno == "maybe" %}true{% else %}false{% endif %}

There are likely many other filters that will behave differently e.g.:

{{ missing|add:"x" }}

Without the patch, if 'missing' is undefined this returns "x", but with 
the patch it returns "". It's not just builtin filters I'm thinking 
about, it's everyone else's that would also have to be made aware of 
this new false-y value that it will start receiving. This is a really 
big backwards incompatible change, I don't see how we could justify 
this. If we were starting from scratch it would be another matter.


Luke

--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fb53a533-9e83-476c-a20d-6bc7953b928c%40cantab.net.
For more options, visit https://groups.google.com/d/optout.


Re: Template handling of undefined variables

2017-03-01 Thread Luke Plant



In the context of template variable interpolation i.e. `{{ }}`
syntax, it is defined that `x` in this case will get converted to
the empty string (or your 'string_if_invalid' setting) -

https://docs.djangoproject.com/en/dev/ref/templates/api/#how-invalid-variables-are-handled


- unlike the case for `if` tags.

When this value (the empty string) is passed to `default_if_none`,
the value is not changed, since it is not None. See

https://docs.djangoproject.com/en/1.10/ref/templates/builtins/#default-if-none




The missing piece of information for me (and even reading the docs 
it's far from obvious) is that undefined variables mean two different 
things in the different contexts.


The value *is* changed in the second case, because it *is* None. 
Undefined values are '' in {{ }} context but are None in {% %} 
context. Maybe that's obvious to you, but it's not to me. In fact, 
after a few minutes searching I still can't find where this is 
mentioned in the documentation. Only the vague statement that invalid 
variables are "generally" replaced with string_if_invalid.


I meant above that in the {{ }} context 'default_if_none' doesn't return 
the default value, but just returns the empty string input value.


I also had to read the docs to understand the behaviour - it is 
mentioned in the 3rd paragraph down in the docs linked above, "How 
invalid variables are handled" - the `if`, `for` and `regroup` tags are 
specifically mentioned.  I think the docs could be clearly about how 
things work with variables passed to template tags etc. "In general" as 
you say is rather vague. Definitely room for improvement here!



Luke

--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/49c674a7-ab69-cfd6-0fdc-9ba444fd1ffa%40cantab.net.
For more options, visit https://groups.google.com/d/optout.


[ANNOUNCE] Django bugfix release: 1.10.6

2017-03-01 Thread Tim Graham
Details are available on the Django project weblog:

https://www.djangoproject.com/weblog/2017/mar/01/bugfix-release/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0d0e8c89-790e-461b-970f-f2e480ef427d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.