Re: Clearing prefetch related on add(), change(), remove()

[bliyanage]

To be clear, I think the way to force the refresh of an orm object is to 
use the `refresh_from_db` method.  Is that functionally equivalent?

-Ben

On Tuesday, June 7, 2016 at 6:12:30 AM UTC-7, Marc Tamlyn wrote:
>
> I may be "too close" to knowing the implementation of this feature to be 
> able to comment on whether the behaviour is surprising to most people, but 
> it doesn't surprise me. It's certainly analogous to that when you do 
> `MyModel.objects.create()` it doesn't change an already executed queryset. 
> There's a question of where you draw the line as well - what about 
> `related_set.update()`?
>
> I think it's worth documenting the behaviour, also noting that you can 
> "force" the execution of a new queryset by chaining another .all().
>
> On 7 June 2016 at 13:26, Yoong Kang Lim  > wrote:
>
>> Hi all, I'd like to bring up ticket #26706: 
>> https://code.djangoproject.com/ticket/26706
>>
>> Related managers have methods such as add(), change() and remove() that 
>> change database objects. When a prefetch_related is done prior to calling 
>> these methods, it does not clear the cache. When the related field is 
>> accessed, it returns the cached result instead of the updated result. A 
>> couple of tickets have been opened, as this does seem to be surprising 
>> behaviour.
>>
>> I was working on a patch to address this, but Tim brought up some 
>> concerns about backward compatibility regarding the change and directed me 
>> here to get some community consensus. The change I'm proposing will clear 
>> the cache (for the prefetched field) when any of the methods are called. If 
>> we introduce this, it will be a backwards-incompatible change, so I'd just 
>> like to get some opinions on what the best way forward would be. Obviously 
>> in either case the behaviour should be documented. 
>>
>> Also a thought just occurred to me -- if we don't put this change in, 
>> could we, as an alternative solution, extend the API to let the user decide 
>> what to do with the cache? Maybe something like 
>> clear_prefetched_field(related_field_name) on the manager so that at least 
>> the user has a choice instead of running the query (although the trouble 
>> they would need to go through would be similar, IMO).
>>
>> -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@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/eabd9567-53e3-413b-9b30-dbcfbf9c2634%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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/21f57884-ba0a-40e4-9a81-28645d059f03%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clearing prefetch related on add(), change(), remove()

[bliyanage]

I am for the clearing of the cache--that behavior seems weird.  If you 
didn't want the cache to clear you would probably be using a different orm 
object to do your query.

Just to be clear, after clearing the cache, any future requests against 
that data will be lazily evaluated right?

-Ben

On Tuesday, June 7, 2016 at 5:26:42 AM UTC-7, Yoong Kang Lim wrote:
>
> Hi all, I'd like to bring up ticket #26706: 
> https://code.djangoproject.com/ticket/26706
>
> Related managers have methods such as add(), change() and remove() that 
> change database objects. When a prefetch_related is done prior to calling 
> these methods, it does not clear the cache. When the related field is 
> accessed, it returns the cached result instead of the updated result. A 
> couple of tickets have been opened, as this does seem to be surprising 
> behaviour.
>
> I was working on a patch to address this, but Tim brought up some concerns 
> about backward compatibility regarding the change and directed me here to 
> get some community consensus. The change I'm proposing will clear the cache 
> (for the prefetched field) when any of the methods are called. If we 
> introduce this, it will be a backwards-incompatible change, so I'd just 
> like to get some opinions on what the best way forward would be. Obviously 
> in either case the behaviour should be documented. 
>
> Also a thought just occurred to me -- if we don't put this change in, 
> could we, as an alternative solution, extend the API to let the user decide 
> what to do with the cache? Maybe something like 
> clear_prefetched_field(related_field_name) on the manager so that at least 
> the user has a choice instead of running the query (although the trouble 
> they would need to go through would be similar, IMO).
>

-- 
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/ad5c2d3f-e00c-42f6-b519-4d294a6c0c78%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Scaling Django for Multiple Teams

[bliyanage]

Hey,

I have two issues I'm looking at solving at work, and I'm looking for a 
couple suggestions as to how other people have solved this.  The two things 
are:

* scale out their django installation to allow for smaller releases (I'm 
thinking microservices, but it could also be internal django apps or who 
knows what else)
* minimizing the impact of migrations during releases (aka we want to be 
able to release in the middle of the afternoon

Currently we put up a maintenance page whenever we are doing database 
operations (aka migrations).  This seems like a recommended best practice.

One way I was thinking about addressing this issue was to break all of our 
models out into a separate repo.  That way we'd only need to deploy 
migrations when the models themselves have deployed.  For code that needs 
the models, we could pip install the repo as an app and away we go.  
Likewise it seems like I could break up different parts of our app via a 
similar strategy.

Does this seem viable?  How have other people solved this kind of problem?

Thanks,

-Ben

-- 
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/d3e0e2f2-3322-462a-a02e-d776c40bc07a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Collectstatic and determine which files need to be updated by comparing their checksum

[bliyanage]

This makes a lot of sense to me.

On Tuesday, April 12, 2016 at 9:07:51 AM UTC-7, Daniel Blasco wrote:
>
> Hi,
>
> I posted this in django-users but I think that it goes better here.
>
>
> I'm using django-storages to upload my static files to Amazon S3 and I'm 
> serving my application from Heroku.
>
> In my local development, when I run collectstatic for a second time just 
> after the first one, no files are being uploaded to S3 because 
> collectstatic checks for the modified_time to determine if the local files 
> are newer than the ones in S3. That's fine so far.
>
> The problem is when I deploy to Heroku. Collectstatic is being executed 
> from the Heroku server and absolutely all the files are always being 
> uploaded to S3, even the ones that have not changed. This is because during 
> the deployment Heroku creates a full copy of the source code, and therefore 
> all the files have a new modified_time. In my case, it takes almost 10 
> minutes to upload ~1000 files for each deployment.
>
> Also, imagine the situation where the modified_times are not being changed 
> and I wanted to upload older versions of the static files. I wont be able 
> because storage wouldn't allow to upload files with an older modified_time.
>
> I think that a more accurate way to check if a file needs to be replaced 
> could be by comparing their checksum/hash and offer this feature for all 
> the Storage subclasses. To preserve backwards compatibility, in 
> collectstatic command first determine if the storage subclass implements a 
> checksum generation and otherwise fallback to modified_time comparison.
>
>
> What do you think, is this something that makes sense?
>

-- 
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/f3ff03ea-968e-44a3-8dfc-b603fbb219b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Collectstatic and determine which files need to be updated by comparing their checksum

[bliyanage]

On Tuesday, April 12, 2016 at 9:07:51 AM UTC-7, Daniel Blasco wrote:
>
> Hi,
>
> I posted this in django-users but I think that it goes better here.
>
>
> I'm using django-storages to upload my static files to Amazon S3 and I'm 
> serving my application from Heroku.
>
> In my local development, when I run collectstatic for a second time just 
> after the first one, no files are being uploaded to S3 because 
> collectstatic checks for the modified_time to determine if the local files 
> are newer than the ones in S3. That's fine so far.
>
> The problem is when I deploy to Heroku. Collectstatic is being executed 
> from the Heroku server and absolutely all the files are always being 
> uploaded to S3, even the ones that have not changed. This is because during 
> the deployment Heroku creates a full copy of the source code, and therefore 
> all the files have a new modified_time. In my case, it takes almost 10 
> minutes to upload ~1000 files for each deployment.
>
> Also, imagine the situation where the modified_times are not being changed 
> and I wanted to upload older versions of the static files. I wont be able 
> because storage wouldn't allow to upload files with an older modified_time.
>
> I think that a more accurate way to check if a file needs to be replaced 
> could be by comparing their checksum/hash and offer this feature for all 
> the Storage subclasses. To preserve backwards compatibility, in 
> collectstatic command first determine if the storage subclass implements a 
> checksum generation and otherwise fallback to modified_time comparison.
>
>
> What do you think, is this something that makes sense?
>

-- 
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/3195691c-483e-479a-afa9-e9d2e002ed85%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting lazy middleware initialization

[bliyanage]

I'm not too familiar with the code you're referencing, but I'm personally 
really annoyed by lazy loading.  It has a tendency to make selenium tests 
timeout inconsistently in CI, as well as give the impression to my bosses 
that the app is slow rather than just the first load which is usually what 
they see on new features.

-Ben

On Thursday, March 24, 2016 at 9:39:50 AM UTC-7, David Evans wrote:
>
> Hi all,
>
> Currently, middleware is initialized lazily on serving the first request, 
> rather than on application start. There may well have been good reasons for 
> this historically, but I don't think they apply any longer. Lazy 
> initialization is unhelpful if a middleware class throws an error (e.g to 
> report a misconfiguration) because the application will appear to start 
> successfully and only later report the error when a request is made.
>
> I'd like to propose initializing middleware when `get_wsgi_application` is 
> called. This solves the problem described above and, as far as I can tell, 
> raises no backwards compatibility issues.
>
> More details on all this below.
>
>
> ### 1. Specific example of the problem
>
> I recently wrote an adapter for the WhiteNoise static file server so it 
> could function as Django middleware as well as WSGI middleware (
> https://github.com/evansd/whitenoise). WhiteNoise may be unusual in doing 
> a non-trivial amount of work on initialization, but it doesn't seem 
> unreasonable. When used as WSGI middleware any errors are triggered 
> immediately on start up, but not so when used as Django middleware. This 
> makes for a worse developer experience and an increased chance of 
> deployment errors.
>
>
> ### 2. Reasons previously given for lazy initialization
>
> There was some brief discussion in this ticket 4 years ago:
> https://code.djangoproject.com/ticket/18577
>
> The reason given there is that "resolving on first request makes most 
> sense, especially for the case where you might not be serving requests at 
> all". Presumably this refers to running non-http-related management 
> commands. But in those cases we never instantiate a WSGI application anyway 
> (wsgi.py is just never imported) so this is no reason not to initialize 
> eagerly when constructing the WSGI application. (Of course, things may have 
> been different 4 years ago.)
>
> Another reason is given in the comments in django.core.handles.wsgi:
>
> https://github.com/django/django/blob/3c1b572f1815c295878795b183b1957d0df2ca39/django/core/handlers/wsgi.py#L154
>
> This says "Set up middleware if needed. We couldn't do this earlier, 
> because settings weren't available". However `get_wsgi_application` (the 
> only public WSGI API) now calls `django.setup()` before constructing the 
> handler so settings are in fact available.
>
>
> ### 3. Proposed solution
>
> My proposal is simply to amend `get_wsgi_application` as follows:
>
> def get_wsgi_application():
> django.setup(set_prefix=False)
> handler = WSGIHandler()
> handler.load_middleware()
> return handler
>
> It's possible that this logic could be moved into the handler's __init__ 
> method. This caused no problems with existing application when I tried it, 
> however it did cause problems with the test suite which seems to rely on 
> the old behaviour in places. The above proposal passes all existing tests 
> as is.
>
>
> ### 4. Backwards compatibility issues
>
> Middleware constructors have no means of accessing the request object or 
> anything that depends on it. They are called right at the start of the 
> handler's `__call__` method before the `request_started` signal is sent and 
> before the `script_prefix` thread-local is set. Therefore it cannot matter, 
> from the middleware class's perspective, whether it is instantiated before 
> or after the first request comes in.
>
>
> I'm aware this issue probably isn't high on anyone else's priority list, 
> but I think it would count as a genuine -- if small -- improvement to 
> Django.
>
> Thanks,
>
> Dave
>

-- 
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/f61a2b50-01e3-48ef-809f-82edc23d9da4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ GSoC2016 ] Integration of django and angular2

[bliyanage]

In terms of a front end application using django views you can totall 
implement angular, and do whatever you want.  If you're proposing that the 
backend be rewritten in angular, I think that is probably unnecessary 
overhead for what the admin is supposed to do, and will make customizing it 
considerably more difficult.

On Wednesday, March 9, 2016 at 12:33:49 PM UTC-8, Вадим Горбачев wrote:
>
> Hello.
>
> I am a student of the St. Petersburg State Polytechnical University.
> But I am also a web-developer 
>  .
>
> Now the problem of integration of django and angular2 is very interesting 
> to me.
> And I want to submit the application in this direction.
>
> *Reason:*
>  There are many decisions on the basis of django + angularJS, 
>  and it is good to aggregate this knowledge that will help many developers 
> not to step on the same rake.
>  Very big contribution to the solution of this problem can be found here 
> . 
>
>  But with an exit of ECMAscript6 and angular2, there is a wish to pass to 
> them somewhat quicker.
>  ECMAscript6 is awesome!
>
> *Question:*
>  Whether there will be interestingly this task to community?
>  Or to look for a work subject more approximate to the offered list?
>
> thanks in advance!
>

-- 
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/41fe1a7d-1504-4e84-adf2-beeb5c987f2f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Composite Primary Keys

[bliyanage]

Sounds cool, I think we would totally use that. 

On Wednesday, February 17, 2016 at 1:55:15 AM UTC-8, Roger Gammans wrote:
>
> Hi, 
>
>
> We've got some patches that we are using in production, against 
> 1.8 . Out long term aim would be to get them ready for a PR , but I they 
> are missing all sorts of things, such unit tests and migrations (we 
> don't use migrations at the moment - long story, so these haven't been 
> tested). The other thing which I think is  maybe is some of the 
> prefetch_related API, I've had difficulties with it and just worked 
> around it in my app. 
>
> And it really needs another user at least to kick the tires which we 
> aren't exercising - we mainly use because we have a lot of intersection 
> tables of natural / 'foreign' keys and a legacy model which didn't add a 
> serialized Pk for these. 
>
> I'd also like to know how interested the core developers would be in 
> merging some support for this. 
>
>
>
> On Tue, 2016-02-16 at 17:38 -0800, Cristiano Coelho wrote: 
> > Hello there, 
> > 
> > What's the status for this? This 
> > (https://code.djangoproject.com/wiki/MultipleColumnPrimaryKeys) is 3 
> > years old (last edit) and the links on it are even older. Googling 
> > around only gave me some very old projects so it wasn't good neither. 
> > 
> > -- 
> > 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-develop...@googlegroups.com . 
> > To post to this group, send email to 
> > django-d...@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/b2873ece-39bb-4536-b23d-d988c7122204%40googlegroups.com.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>
>
>

-- 
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/098addaa-a397-4016-913c-e1a3037d34e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: thinking about the admin's scope and its description in the docs

[bliyanage]

While I think it's true that a process centric workflow (wizards, or hubs 
anyone?) would be incredibly useful, that does not take away from the fact 
that the model centric admins are also incredibly useful, and time saving.  
It's so easy to add search, sorting, bulk actions, etc to an admin--these 
are things I've often spent days or weeks working on in other systems.  
With django it is often a matter of minutes to add these incredibly common 
features.  This is probably one of my favorite things about the django 
framework.

On Wednesday, February 10, 2016 at 5:33:03 PM UTC-8, Curtis Maloney wrote:
>
>
>
> On 11/02/16 00:55, Andy Baker wrote: 
> > I can't help but feel that the "admin is very rudimentary and hard to 
> > customize" is perpetually overplayed by many in the community. Maybe I'm 
> > suffering Stockholm Syndrome but I'd like to raise a dissenting voice. 
>
> I must admit I'm a large proponent of warning against getting caught up 
> in "Admin as my management console". 
>
> As customisable as it can be, I find the problem to be it is a 
> data-centric view of your system, closely tied to the database models. 
>
> IMHO a management interface for site should be a _process_ centric view, 
> abstracting away the implementation details of tables and fields. 
>
> Perhaps a better way to think of it as the difference between a 
> "management" and a "maintenance" interface. 
>
> True, in a lot of cases these can be the same thing, and for simpler 
> sites Admin works "just fine".  However, I've been on too many projects 
> that wind up spending a lot of time and effort customising Admin to do 
> things that would have been simpler in a custom view. 
>
> Worse still, I've seen projects alter their schema design to accommodate 
> Admin's limitations [like lack of nested inlines] 
>
> Is it possible to add other views to admin?  Sure... though it's not 
> clear, or well documented. 
>
> Can documentation alone overcome this problem?  I'm not convinced it can. 
>
> For some years now I've been proposing an investigation into slicing 
> Admin into two layers: a base "management interface framework" layer, 
> and "admin" built atop this framework. 
>
> Then we can keep providing the Admin we all know and love, and also make 
> it easier for people to build their own management interfaces. 
>
> However, I don't currently have the time [or admin familiarity] to 
> undertake this work. 
>
> -- 
> Curtis 
>

-- 
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/26ee6e6b-f5dd-4959-a8d9-d1be6acfad4b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PostGres 9.5 Upsert

[bliyanage]

After thinking about it a bit, I think the only function that would really 
benefit from this would be the update_or_create.  If you're doing 
get_or_create you still need a second query to get the actual row.

On Friday, January 8, 2016 at 4:13:26 PM UTC-8, bliy...@rentlytics.com 
wrote:
>
> Hey Guys,
>
> Postgres 9.5 has added the functionality for UPSERT aka update or insert.  
> Any interest in aligning UPSERT on the db layer with the get_or_create or 
> update_or_create functionality in django?  Sounds like my company would be 
> interested in doing the work if the PR will get the traction.
>
> -Ben
>

-- 
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/858c3f77-a20c-413e-9e76-78435b589658%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

PostGres 9.5 Upsert

[bliyanage]

Hey Guys,

Postgres 9.5 has added the functionality for UPSERT aka update or insert.  
Any interest in aligning UPSERT on the db layer with the get_or_create or 
update_or_create functionality in django?  Sounds like my company would be 
interested in doing the work if the PR will get the traction.

-Ben

-- 
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/eaf86518-a1b0-465c-9bf0-de724ae50d7f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: MOSS Award to Django

[bliyanage]

Hey,

Channels sounds a lot like celery (or celery sounds like part of 
channels).  Is that a fair read?  Looking for tighter REST integration 
either way.

Thanks,
-Ben

On Friday, December 11, 2015 at 10:19:00 AM UTC-8, Andrew Godwin wrote:
>
> Hi everyone,
>
> For those who haven't seen, Mozilla has awarded $150,000 to Django for 
> work on Channels and request/response improvements lifted from REST 
> Framework. More in the blog post here: 
> https://www.djangoproject.com/weblog/2015/dec/11/django-awarded-moss-grant/
>
> I'll be coordinating this effort for the most part, but we're still 
> working out who to fund and the roadmap for the project, as well as work 
> out how we can pay people for their work on a different scale to the Django 
> Fellowship, so it might take a bit of time!
>
> I'll be back on here with some questions for people to discuss/answer 
> about the channels design at some point soon, but a lot of the basic design 
> is already up at http://channels.readthedocs.org, so take a read over 
> that if you're interested.
>
> What I can say is that my intention is to both bake Channels into the next 
> major release of Django, as well as hopefully release a pluggable app 
> version that will run on 1.8 and 1.9 - I have some plans around how to do 
> that effectively, but they involve hitherto unforged paths around Django 
> and how we package dependencies, so I can't say we'll get there 100%.
>
> Andrew
>

-- 
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/299ede52-6ae4-46d3-8667-40e7fa6a89a6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: __ne, #5763

[bliyanage]

I have to say, the lack of __ne is very inconsistent for people new to 
django, but veterans at sql.  It's just one more frustration point when 
you're trying to learn a new ORM.

-Ben

On Friday, November 20, 2015 at 11:37:02 AM UTC-8, Carsten Fuchs wrote:
>
> Hi all,
>
> sorry if this is a stupid question, but after having read 
> https://code.djangoproject.com/ticket/5763 and the discussions linked 
> from it, why should __ne not be implemented?
>
> Without __ne, I'm experiencing the same problems that asmoore82 described 
> at https://code.djangoproject.com/ticket/5763#comment:23
> That is, afaics, some queries cannot be formulated without __ne, as 
> exclude() is not an equivalent. Or am I missing or misunderstanding 
> something?
> I can live with the existing work-arounds, so I'm mostly curious.   :-)
>
> Best regards,
> Carsten
>
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d227ef16-be32-4b6e-8fe7-f91ea5979ee1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Should contrib.auth include support for 2fa out of the box?

[bliyanage]

+1

This sounds like a great feature, depending on the implementation.

On Monday, October 26, 2015 at 10:22:46 AM UTC-7, Tim Graham wrote:
>
> On Trac [1], Alex says, "Django did a tremendous service to its users by 
> making strong password hashing be the default. The world is pushing 
> forward, and now 2fa is the next standard that many sites fail to meet. 
> Django should include support for 2fa out of the box, ideally with support 
> for both u2f and TOTP (Google Authenticator)."
>
>
> Doing a quick search, I found 
> https://github.com/Bouke/django-two-factor-auth as a possible existing 
> implementation that might be a starting point if we decide to integrate 
> something. What do you think? One sticking point could be that it uses a 
> ThreadLocals middleware. I didn't look to see how "necessary" that is.
>
>
> [1] https://code.djangoproject.com/ticket/25612
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/37f2ad54-c6c0-4e13-a1a3-bd44a1c6adc6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Feature] On CommandError, sys.exit(1)

[bliyanage]

Hm, let me check it out and get back to you.  We had some migrations that 
exited in failure, but with a non-0 exit status during our release.  I'll 
see if I can reproduce this this week.

-Ben

On Monday, October 26, 2015 at 11:21:17 AM UTC-7, Tim Graham wrote:
>
> The place you linked to is ignoring CommandError when parsing arguments. 
> I'm not sure under what conditions this happens (if at all) -- the Django 
> tests don't cover it.
>
> As far as I know, BaseCommand already does sys.exit(1) when there's an 
> unhandled exception: 
> https://github.com/django/django/blob/df0a446fd4c864c003e4f941b5b7abd6f10c9427/django/core/management/base.py#L289-L300
>
> Could you clarify how to reproduce the problem you're seeing?
>
> On Monday, October 26, 2015 at 2:01:17 PM UTC-4, bliy...@rentlytics.com 
> wrote:
>>
>> Is it ok if I do a PR on this?  This seems like it would be really useful 
>> for automation.
>>
>> -Ben
>>
>> On Thursday, October 22, 2015 at 2:20:18 AM UTC-7, Ben Liyanage wrote:
>>>
>>> Hey,
>>>
>>> What do you guys think about this feature request?
>>>
>>> > On CommandError, sys.exit(1)
>>>
>>> It would be pretty easy to do the sys.exit(1) right here: 
>>>
>>>
>>> https://github.com/django/django/blob/df0a446fd4c864c003e4f941b5b7abd6f10c9427/django/core/management/__init__.py#L289
>>>
>>> This would allow you to fail an automated build when migrations (or any 
>>> other management command) failed.  Currently I see no way of doing that.
>>>
>>> Beyond that, I noticed that the sys.exit(1) is not very consistently 
>>> applied on the makemigrations management command (for example, it is not 
>>> called when the --merge parameter is supplied).
>>>
>>> I can do the PR for the CommandError thing (unless anyone sees a reason 
>>> not to, or that would not work/there is a better place to put it).
>>>
>>>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/794a8e8b-2938-4cae-9245-9bdf056ae6ca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

[bliyanage]

> -1 on changing the check of usernames at login to case-insensitive
> +1 with preventing the creation of new usernames

Ditto

On Thursday, October 22, 2015 at 9:33:02 AM UTC-7, mtnpaul wrote:
>
> Yeah, I was referring to the post by Daniel at the start of the thread, 
> not Reid's comment.
>
> I would be -1 on changing the check of usernames at login to 
> case-insensitive. But I would be +1 with preventing the creation of new 
> usernames which would match existing usernames in a case-insensitive manner.
>
> On Wed, Oct 21, 2015 at 3:39 PM, Shai Berger  > wrote:
>
>> Hi,
>>
>> On Thursday 22 October 2015 00:01:24 Paul Egges wrote:
>> > Perhaps I'm missing something, but this would not change current users,
>> > only the creation of new users. It seems that logins would still be case
>> > sensitive.
>>
>> Not the way Reid presented it:
>>
>> > > Le mercredi 21 octobre 2015 15:44:55 UTC-4, Reid Ransom a écrit :
>> > >> Is it reasonable to consider changing the default for usernames to be
>> > >> case-insensitive in 2.0?
>>
>> I think, though, it would be easy enough for us to provide a new, case-
>> insensitive base class for users, and change the recommendations in our
>> documentation to tell users to inherit that rather than the current
>> AbstractBaseUser and AbstractUser. We could also write a simple management
>> command to validate lower-case uniquness and turn all usernames to 
>> lowercase,
>> as preparation for changing the login and registration logic.
>>
>> These could all be done outside of core, and perhaps they should be -- the
>> only point I see for including them in core is the risk that, as a 
>> developer,
>> if core doesn't make you think about it from the get-go, by the time you
>> decide to make the change you may be stuck with conflicting (lower-case 
>> equal)
>> usernames in your database. But frankly, I would guess that this problem 
>> does
>> not really occur very often; that for most sites, if they decide to 
>> switch to
>> case-insensitive usernames, there would be no problem.
>>
>> Regretfully, we can't just switch Django to do that, because of the few 
>> sites
>> who will have a problem, and no clear upgrade path.
>>
>> Shai.
>>
>
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9b0d5977-e42e-4e66-a348-e422bf2d252b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Feature] On CommandError, sys.exit(1)

[bliyanage]

Is it ok if I do a PR on this?  This seems like it would be really useful 
for automation.

-Ben

On Thursday, October 22, 2015 at 2:20:18 AM UTC-7, Ben Liyanage wrote:
>
> Hey,
>
> What do you guys think about this feature request?
>
> > On CommandError, sys.exit(1)
>
> It would be pretty easy to do the sys.exit(1) right here: 
>
>
> https://github.com/django/django/blob/df0a446fd4c864c003e4f941b5b7abd6f10c9427/django/core/management/__init__.py#L289
>
> This would allow you to fail an automated build when migrations (or any 
> other management command) failed.  Currently I see no way of doing that.
>
> Beyond that, I noticed that the sys.exit(1) is not very consistently 
> applied on the makemigrations management command (for example, it is not 
> called when the --merge parameter is supplied).
>
> I can do the PR for the CommandError thing (unless anyone sees a reason 
> not to, or that would not work/there is a better place to put it).
>
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1fb4b369-6ced-413d-8a77-edbe03e6c2d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.