[ANNOUNCE] Django 1.10 beta 1 released

We've made the second release on the way to Django's next major release, Django 1.10! With a month and a half until the scheduled final release, we'll need timely testing from the community to ensure an on-time and stable release. Check out the blog post: https://www.djangoproject.com/weblog/20

Re: decorator_from_middleware changes

On Tue, Jun 21, 2016 at 7:00 PM, Carl Meyer wrote: > Still halfway tempted to go with the original "make middleware authors > responsible for this themselves, if they want to access > response.content" approach. > I am curious to hear what others think, but I'm leaning this way too. Having a per

Re: decorator_from_middleware changes

Hi Shai, Apologies, I didn't fully process your suggestion or the reason for the flag the first time. I think it would work, though I'd be tempted to set the flag to False on the transition middleware by default, to provide perfect back-compat for existing uses of decorator_from_middleware until s

Re: Fate of sql* management commands

I'll be happy to look at whatever you come up with or review whatever changes you think need to be made in Django to solve the ticket, however, I fail to understand how Andrew's proposal isn't suitable. Maybe you could give more specific details than "migrations may be corrupted" and "they are

Re: Fate of sql* management commands

> > > So add another step in the end to remove the temporary migrations folder > created just in order to enable sqlmigrate. If you're a real purist, add > yet > another one to make sure you don't have a django_migrations table left > over. > > Sorry, Shai, I doubt you understand the problem.

Re: Fate of sql* management commands

On Wednesday 22 June 2016 00:48:58 Marcin Nowak wrote: > > You can write the "sqlall" you want as a shell script -- remove any > > existing > > migrations, use "makemigrations" to create an initial migratgion, > > Not exactly. I'm not using migrations [.. cut ..] > So add another step in the en

Re: Fate of sql* management commands

> > > You can write the "sqlall" you want as a shell script -- remove any > existing > migrations, use "makemigrations" to create an initial migratgion, Not exactly. I'm not using migrations [.. cut ..] I repeat Aymeric's advice that spreading your frustrations over this > mailing > l

Re: Fate of sql* management commands

Marcin, You can write the "sqlall" you want as a shell script -- remove any existing migrations, use "makemigrations" to create an initial migratgion, which will exactly reflect your models, and run sqlmigrate on that. You want to do that against a clean database, to make sure no migration has

Re: Fate of sql* management commands

On Tuesday, June 21, 2016 at 10:55:13 PM UTC+2, Marcin Nowak wrote: > > > Somebody wrote eariler that `sql*` commands can be written as an external > app/package. They can't. Django internals must be fixed before this, or new > app must provide complete solution including sql generator like SE

Re: Fate of sql* management commands

On Tuesday, June 21, 2016 at 5:49:08 PM UTC+2, Marcin Nowak wrote: > > > > On Tuesday, June 21, 2016 at 4:00:51 PM UTC+2, Tim Graham wrote: >> >> No, it's not as simple as reverting the removal commit [0]. All the >> legacy schema generation methods are removed too [1]. >> > We don't want to ad

Re: decorator_from_middleware changes

Hi Carl, On Tuesday 21 June 2016 19:32:15 Carl Meyer wrote: > Hi Shai, > > On 06/20/2016 11:07 PM, Shai Berger wrote: > > Well, we can change decorator_from_middleware to introspect the > > middleware itself and decide accordingly: > > > > -- if it does not have process_request or process_respon

Re: status of 1.10 release blockers

The blocker is merged so I'll release the beta in a couple hours if no one stops me. On Monday, June 20, 2016 at 9:10:12 PM UTC-4, Tim Graham wrote: > > The remaining blocker: > > UserCreationForm doesn't call normalize_email and normalize_username > https://code.djangoproject.com/ticket/26719 >

Re: decorator_from_middleware changes

On 06/21/2016 10:53 AM, Carl Meyer wrote: > If we're OK in the long term with making middleware-turned-decorator > authors responsible for correctly handling TemplateResponse themselves, > we should just go there right away via > https://github.com/django/django/pull/6765 -- we can take care of > b

Re: decorator_from_middleware changes

Hi Tobias, On 06/21/2016 06:22 AM, Tobias McNulty wrote: > On Mon, Jun 20, 2016 at 10:51 AM, Carl Meyer > wrote >> Possible disadvantages of this approach: > > > >> 3. The new behavior may surprise some people accustomed to the old >> behavior, since it means the effe

Re: decorator_from_middleware changes

Hi Shai, On 06/20/2016 11:07 PM, Shai Berger wrote: > Well, we can change decorator_from_middleware to introspect the middleware > itself and decide accordingly: > > -- if it does not have process_request or process_response as callable > attributes, and it is callable itself, it is a new-style

Re: Fate of sql* management commands

On Tuesday, June 21, 2016 at 4:00:51 PM UTC+2, Tim Graham wrote: > > No, it's not as simple as reverting the removal commit [0]. All the legacy > schema generation methods are removed too [1]. > We don't want to add them back > I know. > but rather use the SQL generation from the migrati

Re: Binding LiveServerTestCase bind to port 0

I'm inclined to make the changes, skip the deprecation, and react appropriately if anyone raises a use case that can't be achieved with the new "bind to port 0" technique. I found a few more things that could be removed, for example the "manage.py test --liveserver=..." option. Only creating a

Re: Fate of sql* management commands

No, it's not as simple as reverting the removal commit [0]. All the legacy schema generation methods are removed too [1]. We don't want to add them back but rather use the SQL generation from the migrations system (SchemaEditor classes). Please read this thread closely and look at Andrew's pull

Re: Fate of sql* management commands

On Tuesday, June 21, 2016 at 3:28:26 PM UTC+2, Tim Graham wrote: > > Marcin, what are you hoping to accomplish with your latest mail? As > Aymeric said in another thread, repeated complaining is not going to help. > Sorry for that. I'm just overhelmed and tired of "fighting" with missing thin

Re: Fate of sql* management commands

Marcin, what are you hoping to accomplish with your latest mail? As Aymeric said in another thread, repeated complaining is not going to help. There's already an accepted ticket for this feature. If you want to be productive and helpful, pick up Andrew's patch and try to complete it. Alternative

Re: Threads and db connection handling question

On Tuesday, June 21, 2016 at 2:34:11 PM UTC+2, Aymeric Augustin wrote: > 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

Re: Fate of sql* management commands

On Monday, June 1, 2015 at 5:11:27 PM UTC+2, Andrew Godwin wrote: > > OK, so I've just gone ahead and done the initial work on this: > https://github.com/django/django/pull/4729 > > They shot not only in my head - http://stackoverflow.com/questions/35455706/equivalent-of-sqlall-in-django-1-9 G

Re: Threads and db connection handling question

On 21 Jun 2016, at 12:53, Marcin Nowak 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

Re: decorator_from_middleware changes

On Mon, Jun 20, 2016 at 10:51 AM, Carl Meyer wrote > Possible disadvantages of this approach: > 3. The new behavior may surprise some people accustomed to the old > behavior, since it means the effect of the middleware decorator won't > occur immediately where the decorator is applied. E.g. if

Re: Threads and db connection handling question

> From version to version it turns more into handy tool for blog > creators/webdesigners > Don't get me wrong. For smal/short-term projects (up to 1-2yr of operation) I'm still using Django and I would recommend it everyone for that kind of job. For long-term projects the first thing that w

Re: Threads and db connection handling question

On Saturday, June 4, 2016 at 12:12:42 AM UTC+2, Cristiano Coelho wrote: > > Aymeric, I have never said anything about connection pool, I'm talking > about thread pooling to perform async work > I have similar requirements and issues with Django. It looks like it is completely unreliable in asy