Re: Requiring GitHub login for actions on Trac

On Friday 08 August 2014 01:49:55 Ben Finney wrote: > Aymeric Augustin writes: > > GitHub doesn't require creating a new account, since anyone interested > > in contributing to Django should have a GitHub account already to > > submit pull requests. > > This

Re: ORM Optimization for filtering by related existence

I personally use qs = qs.filter(somefield__gte=1) (works if the id field is an integer) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: ORM Optimization for filtering by related existence

On Thursday, August 7, 2014 6:48:22 PM UTC-5, Tim Graham wrote: > > Does .filter(somefield__isnull=False) not work for what you're trying to > do? > If I do .filter(somefield__isnull=False) it tries to do a LEFT OUTER JOIN on the table for somefield instead of a WHERE EXISTS (...) and if

Re: ORM Optimization for filtering by related existence

I think the idea is good, but the implementation you have here isn't desirable. Maybe you could experiment with writing your own custom lookup (https://docs.djangoproject.com/en/dev/howto/custom-lookups/) and see if it fits into the framework that way. AFAIK, anything requiring .extra should

Re: ORM Optimization for filtering by related existence

Does .filter(somefield__isnull=False) not work for what you're trying to do? On Thursday, August 7, 2014 7:43:07 PM UTC-4, David Butler wrote: > > It would be nice if there was some database level optimization for getting > objects that have related objects that exist. > > This is a slow filter:

ORM Optimization for filtering by related existence

It would be nice if there was some database level optimization for getting objects that have related objects that exist. This is a slow filter: qs = [obj for obj in qs if qs.somefield_set.exists()] Could be faster with something like this: qs = qs.filter(somefield__exists=True) Here is some

Re: Requiring GitHub login for actions on Trac

Aymeric Augustin writes: > GitHub doesn't require creating a new account, since anyone interested > in contributing to Django should have a GitHub account already to > submit pull requests. This seems to be a common assumption, but it's not true — unless you

Re: Proposal: Password Validity Layer

The custom user idea did seem like a good one to me. I don't think you'd have to rewrite much (anything?) if the only change in your custom user is to add a validate_password() function. If you'd like code up a proof of concept we can take a look. I don't think front-end integration is

Re: Proposal: Password Validity Layer

I actually think Colin's approach seems the best. Have a validate_password function that can be overridden by a custom user model. Tim, if I wanted to move this forward, what would be the next steps? I looked at the trac ticket you mentioned and it looks much more in-depth (full javascript /

Re: Requiring GitHub login for actions on Trac

> I'm sorry. Please accept my apologies and let me rephrase that without > spam-fighting-induced frustration: > > "Other than reducing spam, Django as a project will benefit from this > change be freeing core dev time and energy currently used to delete > spam manually and tweak a feeble

Re: Requiring GitHub login for actions on Trac

Hi, Aymeric, Thank you for your e-mail. I sympathize with your frustration. On Thu, Aug 7, 2014 at 3:27 PM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > Indeed, but I’m dismissing this argument because GitHub is the > pragmatic choice, whether you like it or not. Also, this

Re: Requiring GitHub login for actions on Trac

Hi Andre, On 7 août 2014, at 19:57, Andre Terra wrote: > On Thu, Aug 7, 2014 at 3:46 AM, Aymeric Augustin > wrote: > On 7 août 2014, at 02:58, Andre Terra wrote: > > > Most importantly, how would Django as a

Re: Requiring GitHub login for actions on Trac

On Thu, Aug 7, 2014 at 3:46 AM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > On 7 août 2014, at 02:58, Andre Terra wrote: > > > Most importantly, how would Django as a project benefit from this > > choice other than reducing minimal spam? > > Did you just

Re: Requiring GitHub login for actions on Trac

+1 on GitHub OAuth. I've avoided filling or commenting on bugs because setting up Yet Another Account was enough friction that I never did it. On Thursday, August 7, 2014 2:21:06 AM UTC-5, Erik Romijn wrote: > > > Using GitHub makes sense as it's very likely a new contributor already > has a

Re: multiple django projects on same database schema

This mailing list is for the development of Django. Please direct questions about how to use Django to the django-users mailing list. Regards, Michael Manfre On Aug 7, 2014 12:06 PM, "Héctor Urbina" wrote: > Hello, > > I'm developing a django project for my office, a small

multiple django projects on same database schema

Hello, I'm developing a django project for my office, a small project management system. I'm doing some tries to incorporate a third party document management system, namely mayan-edms, by making use of the same database, so that users maintain theirs credentials. Is that good practice?.

Re: Requiring GitHub login for actions on Trac

On Thu, Aug 7, 2014, Schmitt, Christian wrote: >Currently we already live in a world were everything gets connected. And >that is really awful. One must consider that Github is definitely a target >for intelligence agencies. And I don't mean the NSA only. >Maybe I'm a

Re: Requiring GitHub login for actions on Trac

Absolutely +1. Clearly the most pragmatic choice. On Thursday, 7 August 2014 13:43:45 UTC+1, Josh Smeaton wrote: > > I don't think "vendor lock in" is a good enough reason to avoid it. If > GitHub were to go away, the move to a new code platform would be the > greater problem. Also, nothing

Re: Requiring GitHub login for actions on Trac

I don't think "vendor lock in" is a good enough reason to avoid it. If GitHub were to go away, the move to a new code platform would be the greater problem. Also, nothing will be "lost". The old usernames will still be there, they just won't be properly linked to your github username. I don't

Re: [Discussion] Legacy documentation / Boken docs Django v1.2

I'm in favor of discontinuing older version of the docs. I recently fixed the 1.3 documentation builder since there were several complaints, but no one has complained about 1.2. On Thursday, August 7, 2014 7:32:25 AM UTC-4, Areski Belaid wrote: > > Hi Folks, > > I wanted to open a discussion

Re: Requiring GitHub login for actions on Trac

Thank you for working on this, Aymeric. I am definitely +1 on moving to GitHub as sole authentication provider for trac. We could argue about this forever. In the mean time the spam will pile up, core developers will have to spend time deleting all of it, and eventually we'd come to a plan which

Re: Requiring GitHub login for actions on Trac

I'm a little bit concerned about that. First I'm using a different user on Trac than on Github, so everything I wrote so far will getting lost (not that bad problem for me), but I think there are many users who are in the same situation. The next thing is vendor lock-in. What will happen if

Re: Requiring GitHub login for actions on Trac

To be clear, I have a working implementation of GitHub OAuth that I can activate as soon as we reach a consensus. On 7 août 2014, at 02:43, Ben Finney wrote: > −1. I am happy to agree to Django's BTS terms of use, not GitHub's. > Please don't make the former depend