So in the end, i have to manually close the database connection after my 
threads in my threadpool are done executing, even though, django created 
them automatically when the threads were first created? This is just plain 
bad design.

On Tuesday, June 21, 2016 at 6:04:11 PM UTC+5:30, Aymeric Augustin wrote:
>
> On 21 Jun 2016, at 12:53, Marcin Nowak <marcin...@gmail.com <javascript:>> 
> wrote:
>
> It looks like it is completely unreliable in async environment, and the 
> worst thing is that I can't force Django to create new connection within 
> the thread/process.
>
> Well, they'll say that Django is not designed for that cases. Maybe. My 
> advise - don't use Django for medium and big projects.
>
>
> Hello Marcin,
>
> I fail to see how you get from “I’m having trouble using an async 
> framework with Django” to “Django only works for small projects”. Indeed, 
> using Django in an “async” context requires special care, until channels 
> land — quotes around “async” because I don’t know whether you’re talking 
> about gevent or asyncio or something else.
>
> However, I know multiple Django-based projects containing millions of 
> lines of codes that took hundreds of man.years to build, maintained by 
> dozens of developers. That works fine. There’s no fundamental reason making 
> Django unsuitable for such projects. It tends to scale better than other 
> technologies thanks to strong conventions and limited use of magic.
>
> Regarding database connections, if you weren’t using Django, you’d have to 
> create a database connection with something like `psycopg2.connect()` and 
> dispose of it with `connection.close()` when you no longer need it. When 
> you’re using the Django ORM, database connections are opened automatically 
> when needed. You still have to close them manually if you aren’t working 
> within the traditional request-response cycle.
>
> If the implicit connection establishment is causing trouble, it shouldn’t 
> be hard to write a custom database backend that doesn’t have this behavior. 
> You would add a method to establish a connection and raise an exception in 
> connection.get_new_connection() 
> <https://github.com/django/django/blob/fff5dbe59ca629c295480693f045f03537858eee/django/db/backends/base/base.py#L149>
>  if 
> the connection is already established.
>
> You’re writing that you can’t force Django to create a new connection. 
> That’s as simple as connection.ensure_connection() 
> <https://github.com/django/django/blob/fff5dbe59ca629c295480693f045f03537858eee/django/db/backends/base/base.py#L200>,
>  
> possibly after connection.close() 
> <https://github.com/django/django/blob/fff5dbe59ca629c295480693f045f03537858eee/django/db/backends/base/base.py#L266>
>  if 
> you want to close a pre-existing connection. ensure_connection() is a 
> private API, but you’re already in unsupported territory if you’re running 
> Django within an async framework, so that isn’t making your situation 
> significantly worse.
>
> Spreading FUD about Django’s supposed unsuitability for non-trivial 
> projects isn’t going to help with your issues and isn’t going to create a 
> context where people will look forward to helping you, so please consider 
> avoiding gratuitous attacks if you need further help.
>
> Best regards,
>
> -- 
> Aymeric.
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d6eddc53-fa1a-4be4-94b8-a76fc8e04d0b%40googlegroups.com.

Reply via email to