Re: auth.User refactor: reboot

Also, even if we decide to use django-primate's monkey patch to mount a user model on django.contrib.auth.models.User I think we should still consider breaking AbstractUser into orthogonal mixins. As it stands, AbstractUser is a monolithic model with an ad-hoc method for overriding fields. As a

Re: auth.User refactor: reboot

On Mar 22, 2012 10:55 PM, "Russell Keith-Magee" wrote: > * This solution still has the circular dependency, because any app with a ForeignKey(settings.USER_MODEL) needs to have a settings import in the models.py file Hmmm. I asked a question about that today and was

Re: auth.User refactor: reboot

On 23/03/2012, at 9:50 AM, Alex Ogier wrote: > I hope you don't mind, I added solution 2a. It's basically solution 2 minus > the monkey-patching and resultant circular dependency issues, and > correspondingly requires apps to opt-in to supporting pluggable Users. It > documents the reasoning

Re: auth.User refactor: reboot

On Thu, Mar 22, 2012 at 8:14 PM, Russell Keith-Magee < russ...@keith-magee.com> wrote: > > On 17/03/2012, at 12:53 AM, Jacob Kaplan-Moss wrote: > > > I think we need to come together and agree on an approach before we move > forward, so I'd like to see some concrete proposals for each of these >

Re: Status of issue 17758: dict ordering bugs

Hi, Thanks Aymeric for committing the ORM related fix. As Ramiro suggested, I created a separate ticket for the bug in dependency_order() function - #17954. While it's always nice to have more bugfixes, it doesn't qualify as a release blocker anymore. Looking forward to 1.4 final soon :) --

Re: Contrib backwards-compatibility question

Hi Alex, On 03/22/2012 11:26 AM, Alex Ogier wrote: > Is it considered a backwards incompatibility to import > django.conf.settings at the top level in a contrib models.py file > (specifically, contrib.admin)? I know it's possible to do so, for > example contrib.comments.models imports it, but it

Contrib backwards-compatibility question

Is it considered a backwards incompatibility to import django.conf.settings at the top level in a contrib models.py file (specifically, contrib.admin)? I know it's possible to do so, for example contrib.comments.models imports it, but it could cause circular dependencies for any project that in

Re: Status of issue 17758: dict ordering bugs

On 22 March 2012 16:54, Aymeric Augustin wrote: > Le 22 mars 2012 13:22, Łukasz Rekucki a écrit : >> If the whole patch can't be merged, lets at least fix that bug[2]. Is >> there any work I can do to make it happen? >> [2]: >>

Re: auth.User: The abstract base class idea

> > It looks OK, but there is one really big issue with your approach - > database blowup. > You can easily choose mixins to compose your User model, but once it's > done your database layout is fixed. > If you then decide to use different mixins - it would be impossible > without very smart db

Re: Status of issue 17758: dict ordering bugs

Le 22 mars 2012 13:22, Łukasz Rekucki a écrit : > If the whole patch can't be merged, lets at least fix that bug[2]. Is > there any work I can do to make it happen? > [2]: > https://github.com/lqc/django/commit/84dc450ec861e34de068fde891537f0481342ef7 Hi Łukasz, Let's try

Re: Status of issue 17758: dict ordering bugs

On 22 March 2012 13:38, Ramiro Morales wrote: > 2012/3/22 Łukasz Rekucki : > > Maybe we should split these problem reports in their own tickets? > I can do it later today. There probably should be 3 tickets: the ORM bug, the dependency_order() bug and the

Re: auth.User: The abstract base class idea

Maybe we could make every model pluggable. so User model could be defined like this: class User(models.Model): __mixins__ = load_available_mixins(settings.AUTH_MODEL_MIXINS) But AFAICS, Django will suffer from the same issue as PHP register_globals / Rails mass-assignment, because of

Re: Status of issue 17758: dict ordering bugs

2012/3/22 Łukasz Rekucki : > Hi, > > I got a sad message today, that it's most likely that issue #17758 > won't go in to 1.4; While most of the problems addressed by this > ticket are harmless, I really don't think it's a good idea to ship 1.4 > without resolving the ORM bug.

Status of issue 17758: dict ordering bugs

Hi, I got a sad message today, that it's most likely that issue #17758 won't go in to 1.4; While most of the problems addressed by this ticket are harmless, I really don't think it's a good idea to ship 1.4 without resolving the ORM bug. The hash randomization is a security fix. Right now, people