Re: Support Negative Indexing on QuerySets

On Wed, 2013-07-31 at 13:01 +0100, Simon Riggs wrote: > 3) retrieve via DESC, apply LIMIT and then re-sort by ASC using derived table ... > (3) would require two sorts on the data like this > > SELECT * FROM (rest-of-query ORDER BY ... DESC LIMIT n ) ORDER BY ... ASC I haven't followed this

Re: Django git guidelines

On Tue, 2012-05-22 at 04:18 -0700, Anssi Kääriäinen wrote: > if the patch author doesn't do the final squashing, then > she/he will not end up as the "Author" in the commit logs. This isn't an issue. Just do: git commit --author "John Doe " And if the "squash merge"

Re: Brute force attacks

On Fri, 2011-03-04 at 17:22 -0500, Shawn Milochik wrote: > the thread referred to above discusses throttling, whereas the > "recommendation" provided to us by the auditors was user lockout > requiring administrator activity (human intervention) to unlock. This *creates* a denial of service

Re: Ticket #15124: BooleanField should not use False as default (unless provided)

On Thu, 2011-02-03 at 13:46 -0500, Tobias McNulty wrote: > the behavior of all fields, except for BooleanField, is to default to > the empty value supported by that field. ... > On the other hand, False is in no way an "empty value." From the point of view of the model layer, your point makes

Re: Kilobyte or Kibibite

On Wed, 2011-01-12 at 21:26 +0800, Russell Keith-Magee wrote: > Until I start seeing kibibyte being used in the New York Times, or the > prefered usage in the Chicago Manual of Style, the kibibyte is little > more to me than an intriguing expression of pedantry. Yes, the > existing usage is

Re: CSV serializer?

We have a CSV view (not a serializer) that is linked from every change_list page. This allows sufficiently privileged users to dump the database table into Excel to do things not covered by our existing views. We do not allow for a CSV import, but it's been something that we've wanted. We'd be

Re: About the django-core mailing list

On Thu, 2010-09-09 at 12:30 -0500, Jacob Kaplan-Moss wrote: > 1. Security-related issues. When we receive a security report, we need > to discuss it in private. Just as a data point... I'm a committer on a widely-used open source application, and we discuss these things on a "packagers" list. As

Re: Cross-field Model Validation and Ticket #13100 (Was: Re: High Level Discussion about the Future of Django)

On Mon, 2010-04-19 at 15:44 -0500, Richard Laager wrote: > In the end, *my* requirement is that I have *some place* to put > validation code that 1) can see the whole model instance, 2) will be run > from the admin interface, and 3) will return nice validation failures to > the use

Cross-field Model Validation and Ticket #13100 (Was: Re: High Level Discussion about the Future of Django)

-04-19 at 10:53 -0500, James Bennett wrote: > On Mon, Apr 19, 2010 at 10:16 AM, Richard Laager <rlaa...@wiktel.com> wrote: > > On Mon, 2010-04-19 at 07:55 -0700, orokusaki wrote: > >> With all respect, you still haven't addressed my main concern: You > >> told m

Re: High Level Discussion about the Future of Django

On Mon, 2010-04-19 at 07:55 -0700, orokusaki wrote: > With all respect, you still haven't addressed my main concern: You > told me that it was because of backward compatibility that this simple > change couldn't be put in the trunk. It is backward compatible. If I'm > wrong, it would suffice to

Re: Issues with .only() and Meta.verbose_name{,_plural} inheritance

On Tue, 2010-04-06 at 23:33 +0300, Jerome Leclanche wrote: > The following code reproduces an issue I'm getting on prod with > verbose_name. When using .only(), the class changes, and Meta does not > get inherited. > > Trac is being even more terrible than usual, I've been trying to file > a bug

Re: GSoC: Data importation class

On Thu, 2010-03-25 at 11:34 -0500, Malcolm Tredinnick wrote: > That's not a correct statement, since Django models can often be used to > proscribe conditions on new data that is created via the web app, yet > those conditions might not be required for the universal set of data > that already

Re: Admin refactoring

On Wed, 2010-02-10 at 02:41 -0800, PauloS wrote: > If we are talking about refactoring Admin code (not only html/css > stuff), do you guys think it can be more decoupled from Django ORM? How so? > Is it possible to design some abstraction middleware to loose the bond > between admin and Django

[PATCH] RawQuerySet one-liner

There's a small bug in RawQuerySet. It breaks (returns a deferred model instance instead of a regular model instance even when the appropriate column is SELECTed) with models that have a ForeignKey with a db_column specified. For example: created_by = ForeignKey('User', db_column='created_by')

Re: Ticket #8425 and USStateField (again)

On Thu, 2009-12-24 at 11:44 +0800, Russell Keith-Magee wrote: > This is completely backwards compatible as long as we keep > "STATE_CHOICES" to the same subset that exists today. Yikes, that's really restrictive. You want that list to remain static until Django 2.0? I ask because the Canadian

Re: Problem with history view in admin page

On Tue, 2009-11-24 at 20:54 -0800, Mario Briggs wrote: > Instead we will let users run into errors when they do a '=' compare > of a Django Text type, and then let them ponder whether they need that > column as a CLOB in the backend. Shouldn't something be changing that = into a LIKE (and

Re: Public method for getting model field names in order of definition

On Mon, 2009-11-23 at 04:56 -0800, Anssi Kaariainen wrote: > Here is a working example. > data = {'field1': 'Foo', 'field2': 10} > form = Example(data=data) Thanks for the example, but that's not a ModelForm. Richard -- You received this message because you are subscribed to the Google

Re: Public method for getting model field names in order of definition

On Sat, 2009-11-21 at 05:57 -0800, Anssi Kaariainen wrote: > If I am not completely mistaken you can use your ModelForm with > field.label and field.data to get read-only view of the model. I was trying to do something like this today and didn't have any luck. Do you have a pointer to a working

Re: Public method for getting model field names in order of definition

On Wed, Oct 21, 2009 at 6:38 AM, David Chandek-Stark wrote: > one should (probably) use the > "attname" attribute of a field for its name rather than the "name" > attribute. Why's that? I'm using the "verbose_name" attribute of the field and capitalizing the first