Re: Need to get user_id outside of a view

I've had similar use cases where I needed access to the request in a number of places. I've come to the conclusion that any code that is expected to operate under wsgi (and only under wsgi, and not via management commands) to use thread locals. see

Inheriting from multiple ABCs do not follow the MRO for its abstract Managers

While going through the code for ModelBase for reviewing [1] it is unclear to me when inheriting from 2 Abstract models which define Managers, if the concrete model should use the first manager according to the creation counter or it should follow the MRO. I would expect the following test to

Re: created_at / modified_at on all database tables

eed for this to >> be in core imo. >> >> On Wednesday, September 16, 2015 at 7:44:17 AM UTC+2, Aron Podrigal wrote: >>> >>> Hi, >>> >>> I'd like to propose a created_at / modified_at auto field to models so >>> that one can just turn this

created_at / modified_at on all database tables

Hi, I'd like to propose a created_at / modified_at auto field to models so that one can just turn this functionality on by a setting in settings.py or within the models Meta settings. I want these fields on both of the OneToOne related models when using concrete inheritance, thus using a

Re: Feature proposal: Allow shadowing of abstract fields

Bumping up on this again, what are the plans for moving this ahead. -- 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

Re: Composite fields

Hi Thomas, I replied earlier before you posted, looks like my message got sent actually a lot later. having a function like *models.constrain(x, y, unique=True) *makes sense for inline declarations. About null handling, If all columns on the database are null=True and all columns have a null

Re: Composite fields

Hi Thomas, First, thanks for your work. I've had a plan to start working on this feature last week, but I got too many things to work on with higher priority, Thankfully you opted for this, again Thanks. just sharing my thoughts, 1) I like the MoneyField model style definition. 2) I don't

Re: RE Composite fields-/ Multi Primary / Foreign keys

yeah, turns out I got busy with some other work and did not have time to work on this. Fortunately, Thomas has done a lot of great work yet. I'll just follow up on that thread. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to

RE Composite fields-/ Multi Primary / Foreign keys

Hi, I just came across a project that requires this functionality of multi primary/foreign keys. So I'm bumping up this thread again. There

Re: Feature proposal: Allow shadowing of abstract fields

Why should this be treated differently than the general behavior when realted_names clash when you have more than one foreign key to the same model? So as one would normally do set the related_name explicitly to some other value. setting the field to None is just the way of removing a field and

Re: Feature proposal: Allow shadowing of abstract fields

Hi, I also think so, that overriding a field should not need any special protection. But how would you deal with inherited managers on the class that might refer to some overridden field that has changed? -- You received this message because you are subscribed to the Google Groups "Django