Re: Follow-up to "contrib.admin is slow with large, complex datasets"

On Apr 6, 2:45 am, Jacob Kaplan-Moss wrote: > Can you please stop? We all get that you think these tickets are > important. They're on the milestone for 1.1, so they'll be fixed. > Nagging us here doesn't help get your tickets pushed to the front of > the queue. I'm

Re: Why hardcoded unique and db_index?

On Mon, Apr 6, 2009 at 7:18 PM, MS wrote: > > Hi, > > I've been asking this at django-users but haven't received any good > answer. > (thread: > http://groups.google.com/group/django-users/browse_thread/thread/6994f7b37f3f379c > ) That's a pity, but you won't get an

Re: Why hardcoded unique and db_index?

> That's a pity, but you won't get an answer by 'escalating' your issue > to Django developers. Django-dev isn't 'second-level tech support' - > it's a list for discussing the development of Django itself. I'm sorry, it's not my intention to do so. I already solved my problem by patching

add_constraint=False on relation fields

I made a small patch for my local Django install to be able to precise add_constraint=False (default True, normal behaviour) to FKeys/ M2Ms/... As the tin says, it prevents index/constraint creation for that field. I won't bother going through the use cases for this; I know I need it and maybe

Why hardcoded unique and db_index?

Hi, I've been asking this at django-users but haven't received any good answer. (thread: http://groups.google.com/group/django-users/browse_thread/thread/6994f7b37f3f379c ) So I looked into the django code and found this: class ForeignKey(RelatedField, Field): empty_strings_allowed = False

Re: Follow-up to "contrib.admin is slow with large, complex datasets"

On Mon, Apr 6, 2009 at 4:22 PM, mrts wrote: > > On Apr 6, 2:45 am, Jacob Kaplan-Moss > wrote: >> Can you please stop? We all get that you think these tickets are >> important. They're on the milestone for 1.1, so they'll be fixed. >> Nagging us here

Re: Url tag and context variables (Re: #7917)

I accidentally duplicated this ticket (http://code.djangoproject.com/ ticket/10745) but I provided a diff that applies the change. Should I add this to ticket #7917? On Mar 19, 10:48 pm, Malcolm Tredinnick wrote: > On Thu, 2009-03-19 at 19:30 -0700, Ulrich Petri

Re: Using form validation to prevent deletion no longer works (after rev 10206/ticket #9587)

On Mon, Apr 6, 2009 at 3:09 AM, Dan Tallis wrote: > > It's not clear to me from the thread so far whether there has been a > decision to back out 10206 There hasn't been a decision. I'm still thinking about it. > but, to add some more evidence, I would > point out that

Re: Bug or feature: pre_save used on FileField/ImageField doesn't work as in Django 1.0.2

On Thu, Apr 2, 2009 at 12:33 PM, Marty Alchin wrote: > > A related, thus-far-unreported (I think) issue comes up when > attempting to access width_field and height_field attributes on a > model prior to saving the new file. > Actually it looks like this was kinda reported,

Re: Bug or feature: pre_save used on FileField/ImageField doesn't work as in Django 1.0.2

On Mon, Apr 6, 2009 at 1:16 PM, Karen Tracey wrote: > We cannot know for sure what the file name is until it is saved to disk, as > the save operation may tack on underscores when handling race conditions. > Thus we cannot delay file save to a field pre_save routine and

Heads up: backwards-incompatible change to admin actions

Hi folks -- A quick heads-up to anyone already developing admin actions against 1.1 beta: Because of a few bugs in the design of admin actions, I've needed to make a small backwards-incompatible change to the signature of action functions. If you've been defining actions as methods on your

Re: Bug or feature: pre_save used on FileField/ImageField doesn't work as in Django 1.0.2

On Mon, Apr 6, 2009 at 1:56 PM, Marty Alchin wrote: > > On Mon, Apr 6, 2009 at 1:16 PM, Karen Tracey wrote: > > I feel like I'm going around in circles thinking about this one -- is > there > > a way out that someone else sees that I'm blind to? > >

Re: django <--> wsgi

A first stab at the translators is up on github at http://github.com/teepark/django/tree/50b1e97cec14221a846a6338c40f585e40b76960/django/wsgi I've done django views -> wsgi apps, wsgi apps -> django views, and django middleware -> wsgi middleware. i still think that going from wsgi middleware to

Re: Proposal: New transaction API with multiple databases

I dont know if this has been covered in some of the mentioned previous multi db support threads but how is it supposed to work with admin? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To

Re: Proposal: New transaction API with multiple databases

On Mon, Apr 6, 2009 at 5:00 PM, Andreas wrote: > > I dont know if this has been covered in some of the mentioned previous > multi db support threads but how is it supposed to work with admin? > > > It seems rather orthagonal to the admin to me(at least as far as it can be).

Re: Proposal: New transaction API with multiple databases

On Mon, Apr 6, 2009 at 5:04 PM, Alex Gaynor wrote: > > > On Mon, Apr 6, 2009 at 5:00 PM, Andreas wrote: > >> >> I dont know if this has been covered in some of the mentioned previous >> multi db support threads but how is it supposed to work with

Re: Proposal: New transaction API with multiple databases

I guess this just proves there's too many multi db threads and that we are many who're happy Adrian is making it happening. :) On Apr 6, 11:04 pm, Alex Gaynor wrote: > On Mon, Apr 6, 2009 at 5:04 PM, Alex Gaynor wrote: > > > On Mon, Apr 6, 2009 at

Re: django <--> wsgi

On Apr 7, 6:47 am, Travis Parker wrote: > A first stab at the translators is up on github > athttp://github.com/teepark/django/tree/50b1e97cec14221a846a6338c40f585... > > I've done django views -> wsgi apps, wsgi apps -> django views, and > django middleware -> wsgi

Re: Why hardcoded unique and db_index?

On Mon, Apr 6, 2009 at 7:52 PM, MS wrote: > >> That's a pity, but you won't get an answer by 'escalating' your issue >> to Django developers. Django-dev isn't 'second-level tech support' - >> it's a list for discussing the development of Django itself. > > I'm sorry, it's

Re: Why hardcoded unique and db_index?

On Apr 6, 7:18 am, MS wrote: > The OneToOneField's comment tells that `unique` is hardcoded, but it > sounds more like a definition, not an explanation WHY it's like that. UNIQUE CONSTRAINT If you removed the unique constraint from OneToOneFields, what would you get?

Re: add_constraint=False on relation fields

On Mon, 2009-04-06 at 04:53 -0700, Adys wrote: > I made a small patch for my local Django install to be able to precise > add_constraint=False (default True, normal behaviour) to FKeys/ > M2Ms/... > As the tin says, it prevents index/constraint creation for that field. > I won't bother going

Re: add_constraint=False on relation fields

what would the use cases be? On Mon, Apr 6, 2009 at 6:15 PM, Malcolm Tredinnick wrote: > > On Mon, 2009-04-06 at 04:53 -0700, Adys wrote: > > I made a small patch for my local Django install to be able to precise > > add_constraint=False (default True, normal

Re: add_constraint=False on relation fields

what would the use cases be? On Mon, Apr 6, 2009 at 6:15 PM, Malcolm Tredinnick wrote: > > On Mon, 2009-04-06 at 04:53 -0700, Adys wrote: > > I made a small patch for my local Django install to be able to precise > > add_constraint=False (default True, normal