Re: Feature proposal: Allow shadowing of abstract fields

What was the approach Loic has planned? As Marten had an implementation here [1] just without the locking functionality. Is all the work related to virtual fields done yet? [1] https://github.com/knbk/django/commit/7ac5b58587ea2a153766d1601965734731609cdf On Jul 24, 2015 7:44 PM, "Tim Graham"

Making max_length argument optional

Hi, I am using postgresql and I prefer my VARCHAR columns not to have a length limit. Is there any particular reason why max_length arg to fields is required. If for compatibility with other database backends we can have some sane default if it is None. -- You received this message because you

default values on database level

I would like to propose making Fields.default to rely on the database generated defaults where possible. This could be implemented by having some constants like fields.CURRENT_TIMESTAMP, etc. The tricky part here is to detect database backend specific capabilities and have a python equivalent

Re: default values on database level

t think we should create them by default, instead I propose > the introduction of a db_default kwarg, which should be either a constant, > or an expression (e.g. > db_default=contrib.postgres.functions.TransactionNow). > > Cheers, > Loïc > > > On Jul 29, 2015, at 12:04, Podr

Re: default values on database level

29, 2015 at 11:42 AM, Podrigal, Aron <ar...@guaranteedplus.com > > wrote: > >> Hi Loic, >> >> Agree with having a db_default kwarg. >> >> I am not using multiple databases so no experiance with db routers. So >> how would should we handle r

Re: default values on database level

tion()', F('column1'), 'NOW()'). On Wed, Jul 29, 2015 at 11:58 AM, Podrigal, Aron <ar...@guaranteedplus.com> wrote: > OK, that makes implementation a lot easier. As the model validation can be > done with Model.check() based on the backend given at that time either when > running th

Re: Making max_length argument optional

performance penalty in doing so with all the >> databases that I care about. Also considering we want first class virtual >> field support (and plan on turning existing concrete fields into virtual >> fields) I don't think it's a big problem to break from the existing >&

Re: default values on database level

> On Jul 29, 2015, at 23:05, Podrigal, Aron <ar...@guaranteedplus.com> > wrote: > > > > What about db_default allows either a constent eg. > db_default=contrib.postgres.functions. or a string > "MyCustomPostgresFunction()" and optionaly allowing arg

Re: default values on database level

On Aug 3, 2015 3:36 AM, "Anssi Kääriäinen" wrote: > > On Wednesday, July 29, 2015 at 8:05:10 AM UTC+3, Aron Podrigal wrote: >> >> I would like to propose making Fields.default to rely on the database generated defaults where possible. This could be implemented by having some

Re: The hypothetical models.MultiField: is there a rationale to avoid it ? Or could it make it into future releases ?

Have a look at [1] it is a composite field implementation. [1] https://groups.google.com/forum/m/#!msg/django-developers/MZUcOE6-7GY/sZkBaHvC8wgJ [2] https://github.com/django/deps/blob/master/draft/0191-composite-fields.rst [3]

Re: AbstractUser hierarchy and email-based-users

I'm +1 on this. On Sep 2, 2015 10:31 AM, "'Hugo Osvaldo Barrera' via Django developers (Contributions to Django itself)" wrote: > Hi, > > I've worked on several apps where users don't have a username, and > instead require a unique email. Every time, I've used

Re: Password validation in Django revisited

+1 On Sep 7, 2015 4:56 PM, "Shai Berger" wrote: > On Monday 07 September 2015 20:09:06 Marc Tamlyn wrote: > > I agree with Aymeric and Markus that createsuperuser should not validate > > strength of passwords when DEBUG is on. Having to use a secure password > for > >

Re: Password validation in Django revisited

I started using django-classy-settings and it works very well for me. On Sep 7, 2015 8:04 PM, "Josh Smeaton" wrote: > I don't think removing the default list from the template is the right > idea. We'd be sacrificing some production users that don't go through > security

Re: Making max_length argument optional

On Thu, Jul 30, 2015 at 5:15 AM, Aymeric Augustin < aymeric.augustin.2...@polytechnique.org> wrote: > > Le 29 juil. 2015 à 18:25, Podrigal, Aron <ar...@guaranteedplus.com> a > écrit : > > > > I see models as what defines the database ddl and and not a &

Re: Making max_length argument optional

We're not talking about representing all CharFields as TEXT, it is about choosing a sane length as the default for the varchar datatype. So if you would not specify max_length, for MySQL it would be varchar(255), for oracle it would be varchar(4000 / bytes_per_char_for NLS_CHARACTERSET) and for

Re: Making max_length argument optional

<x...@thebuild.com> wrote: > > On Sep 21, 2015, at 2:49 PM, "Podrigal, Aron" <ar...@guaranteedplus.com> > wrote: > > > We're not talking about representing all CharFields as TEXT, it is about > choosing a sane length as the default for the varchar dat

Re: Making max_length argument optional

://github.com/django/django/blob/9a97f847109d377995a2312e3d569a3dad1da677/django/db/models/fields/__init__.py#L1102-L1109 On Mon, Sep 21, 2015 at 8:52 PM, Christophe Pettus <x...@thebuild.com> wrote: > > On Sep 21, 2015, at 5:49 PM, "Podrigal, Aron" <ar...@guaranteedplus.com&

Re: Making max_length argument optional

, Sep 21, 2015 at 10:03 PM, Christophe Pettus <x...@thebuild.com> wrote: > > On Sep 21, 2015, at 6:12 PM, "Podrigal, Aron" <ar...@guaranteedplus.com> > wrote: > > > The reason for having a max_length set to None, is because that's what I > want for my databa

Re: Making max_length argument optional

On Mon, Sep 21, 2015 at 10:26 PM, Christophe Pettus wrote: > > On Sep 21, 2015, at 7:22 PM, Shai Berger wrote: > > > I'd solve the "need to specify" issue by setting a default that is > > intentionally smaller than the smallest (core) backend limitation,

Re: Making max_length argument optional

meric Augustin" < aymeric.augus...@polytechnique.org> wrote: > Hi Aron, > > On 22 sept. 2015, at 03:12, Podrigal, Aron <ar...@guaranteedplus.com> > wrote: > > > And for your concern, there will be a MaxLengthValidator added to the > validators to validat

Re: Making max_length argument optional

Ok, I'll wait for other contributors to react. On Sep 22, 2015 2:03 AM, "Aymeric Augustin" < aymeric.augus...@polytechnique.org> wrote: > On 22 sept. 2015, at 07:57, Podrigal, Aron <ar...@guaranteedplus.com> > wrote: > > We will be using max_length=255 or 12

Re: Case-insensitive email as username

Why not creating the index as LOWER(email) and do the lookup as LOWER? On Nov 23, 2015 6:18 PM, "Carl Meyer" wrote: > On 11/23/2015 03:52 PM, Carl Meyer wrote: > ... > > I suppose the best we could do to ease this would be to add a > > CreateExtension migration operation in

Re: Allow impossible model validation (mainly admin and generic forms)

I'm also in favor of some solution here. I used to raise a ValidationError with either a particular field if I was able to extract the particular error via regex matches, or as non_field_errors. That was my best I had instead of resulting in a 5xx. In most cases for example a unique race

Re: [Review Request] Added support for database delegated fields (like AutoField)

Like it has been discussed a while ago [1] about adding *db_default*, we should stick with something similar to that and support updates as well. My 2 cents here. I like the idea Anssi has proposed to delegate as much as possible using expressions. So I would propose similar to what discussed in

Re: default values on database level

e. Has anyone > started work on this? If not, I'd like to pick it up. > > -- > Owais > > On Tuesday, August 4, 2015 at 12:05:33 AM UTC+5:30, Michael Manfre wrote: >> >> >> >> On Mon, Aug 3, 2015 at 9:25 AM, Podrigal, Aron <ar...@guaranteedplus.co

Model Meta inheriting ordering from abstract models

Hi, While going through the code for ModelBase I came across the following which I was unable to get it clear from the documentation. A model inheriting from a concrete model does not inherit the Meta class of its parent no matter if it has a Meta of its own. However, it does inherit 2 options,

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

Woop, I forgot the link for [1] Here it comes. [1] https://groups.google.com/forum/#!msg/django-developers/QRvSCTM4WDo/Nehuqfb8BgAJ On Tue, Feb 9, 2016 at 4:26 AM, Aron Podrigal wrote: > While going through the code for ModelBase for reviewing [1] it is unclear > to

Re: Model Meta inheriting ordering from abstract models

I see this was the intention from the very beginning as documented here [1], but wasn't my initial take. I guess it is debatable. In any case updating the documentation to clarify it would be helpful. [1]

Postgres DateTimeRangeField __contains timestamp

Hi, I would like to get some help pointing out where is the ideal place to do these transformations for doing lookups on DateTimeRangeField using __contains=`datetime`. I got a basic working solution at https://github.com/django/django/compare/master...ar45:support_dt_range_contains I would