Re: Extend support for long surnames in Django Auth

FWIW I agree with Florian: - Where the default is unsuitable for a project, it's easier to restrict the field's length in forms than to increase it in the User model. - It's hard to imagine a situation where a 100-character limit is suitable but a 150-character limit isn't. - I

Re: Lazy operations refactor regression with abstract models #25858

It looks like we agree that this depending on import order is not on, so we have no choice but to break behaviour in some cases. Option 1 (don't allow relative references) removes support for relative references in abstract models for everyone. Option 2 (resolve references relative to the

Re: Unneeded index created with unique=True and db_index=False in TextField

I agree this is a bug, and I think it's independent of the discussion of customisable indexes. Postgres creates the necessary index for unique constraints automatically as Tommy said. I'm guessing other backends do too, because the explicit index creation DDL is omitted when unique is True in

Overlap between Func and Transform

Hi list, The thread about reimplementing the date-based lookups[1] reminded me of something that was bugging me a couple of days ago. There's some overlap between Funcs (of arity 1) and Transforms. They seem to fundamentally do the same thing – wrap an expression in some arbitrary SQL – but

Re: Refactor year, month, day lookups?

Hi Josh, With a suitably-defined Month function your example could be: sales_per_month = Model.objects.annotate(month=Month(F('mydate'))).values( 'month').Aggregate(sales=Sum('sale')) ISTM there's a bit of overlap between Func and Transform that could be cleared up - I'll start a new thread

Re: Adding an option on db_index to not create text/varchar_pattern_ops

I agree that this is a problem, and I'd like to see more control over indexes generally in Django. However, at first glance I suspect that fixing only your problem would mean adding special-case gunk to the Field class in addition to the Postgres schema editor where it currently lives[1]. It

Re: Requesting eyeballs on a change to SQLite schema editor

Standalone PR now at https://github.com/django/django/pull/4122. Alex On Thursday, February 12, 2015 at 12:09:39 PM UTC+8, Alex Hill wrote: > > Hi all, doing a bit of yak shaving here. > > I'm currently refactoring Django's lazy operations [0], and ran into a bit > of a sn

Requesting eyeballs on a change to SQLite schema editor

Hi all, doing a bit of yak shaving here. I'm currently refactoring Django's lazy operations [0], and ran into a bit of a snag which led me to make some changes to SQLite's schema editor. All the tests pass, but I thought I should bring this up here to get a few more eyeballs on my changes

Re: Abstract models and the app registry

Hi Carl, Thanks for getting back to me. That all makes sense. I'm still curious as to why abstracts aren't registered – is that a requirement of some feature of the app registry design, or is it just that way because? I think what I would like to do is just declare that string references in

Re: Should annotations allow model field constraints?

Hi Josh, > This is similar to what Ansii thinks the behaviour should be. But we don't > know if a user has provided the field, or if the field is being repurposed > from the underlying field (for F() expressions), or if it was derived > internally. > I was thinking you'd instantiate the

Re: Should annotations allow model field constraints?

First, thanks for all your hard work in this area Josh. >From a quick look at the code, my understanding is that output_field can be None, in which case the ORM will use the model's field type, or it can be specified explicitly in the query. I think that if specified explicitly, any

Re: Displaying (some) M2M fields with through models specified

Thanks Russ, I missed #9475 in my search. I'll have a read through those tickets... ...and back. I'm leaning towards keeping the API as-is, with add/create/remove simply unavailable or raising exceptions if the intermediate model doesn't meet the requirements. A few reasons: 1. As the

Re: RawQuerySet as subquery when used with an __in filter

, 2013 2:35:09 PM UTC+8, Alex Hill wrote: > > Hi Anssi, > > Getting back to this, a year later...I've created a branch on my fork and > opened a ticket on Trac. > > My feature branch: > https://github.com/AlexHill/django/compare/master...raw_subqueries > > Ticket on T

Re: RawQuerySet as subquery when used with an __in filter

/ticket/21604 Would love to get some feedback. Cheers, Alex On Friday, September 7, 2012 5:34:16 PM UTC+8, Anssi Kääriäinen wrote: > > On 6 syys, 11:22, Alex Hill <a...@hill.net.au> wrote: > > Hi Anssi, > > > > Thanks for your feedback! Responses inline. > >

Re: Self-referenced template recursion handling

Hi all, If anybody's interested in some background reading, there is an implementation of this in Mezzanine, using an "overextends" tag. https://github.com/stephenmcd/mezzanine/blob/1.4.16/mezzanine/template/loader_tags.py Cheers, Alex On Sunday, December 8, 2013 11:08:12 PM UTC+8, unai

Re: RawQuerySet as subquery when used with an __in filter

Hi Anssi, Thanks for your feedback! Responses inline. 1. It should not be assumed that the primary key is the field needed > in the inner query. We do have foreign keys to other fields, and one > can use this approach without foreign keys at all. Hmm, yes. Thinking about it, this seems

RawQuerySet as subquery when used with an __in filter

Hi, and thanks for making Django. At the moment, when passing a RawQuerySet to an __in filter, the raw query is evaluated and the result passed as a parameter to the filter's SQL. It would be nice to have the option of using the raw SQL in a subquery instead, for performance reasons. I think