Re: Deletion of related objects

> other deletion cascade strategies, and (2) use DB native > implementations rather than python implementations of deletion where > they are available. This is the goal of #7539, but it's not going to > be a simple change. > > In summary - for me #9308 isn't a wontfix ticket; by

Re: Deletion of related objects

com/ticket/8168 i know y'all are really hating 'new signals' but i'm not sure how to do the myriad of cases without one. Then the user can set things to null or 'ignore it' , change it, etc, etc. And it has the added benefit of not

Re: How do you handle cascading deletes in your production apps?

uires other apps to use a custom subclass for each App and things would get messy fast) just a thought. bo On Dec 10, 6:25 am, AcidTonic wrote: > Currently the cascading delete functionality requires many users to > change how their app works slightly to accommodate this "feature

Re: Proposal: remove auth context processor dependancy for Admin

On Nov 3, 10:24 am, "Collin Grady" <[EMAIL PROTECTED]> wrote: > > I think you're confused - the context processor doesn't set a cookie, > so it isn't causing any Vary behavior, and admin *does* currently > depend on it - it needs the info the processor provides. Unless admin > was rewritten to

Re: Proposal: remove auth context processor dependancy for Admin

d need to override every other function that calls "template.RequestContext' which is most of the meat of sites.py. bo On Nov 1, 1:23 pm, "Collin Grady" <[EMAIL PROTECTED]> wrote: > On Sat, Nov 1, 2008 at 9:45 AM, bo <[EMAIL PROTECTED]> wrote: > > One aid in th

Re: Mysql Ping and performance

Would it be wise to suggest that it be removed from the django core given the connection drops every request? It's not done for Postgres at all and the Oracle base.py is doing what you suggest. I guess this question would be posed to whomever controls that slice of the django pie. bo O

Proposal: remove auth context processor dependancy for Admin

it is present, and use it, otherwise it would simply "add" the three vars (user, messages, perms) to the context itself. I think all it requires is to move the calls to "template.RequestContext" to "self.RequestContext" inside of contrib.admin.site.py .. mak

Mysql Ping and performance

. again not sure if django can solve (or even wants to solve this) .. bo --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@goog

Re: Proposal: Manage.py custom commands overloading

uot;runserver" .. need some way of figuring out "who wins" (either via an option or some guess based on position in an over all import structure) "syncdb" .. can easily run over then entire project, but if a app has its own syncdb run that one instead of the default one.

Proposal: Manage.py custom commands overloading

Hi Guys, While trying out a new WSGI handler, that should run fine in the usual command line "runserver", i noticed that the get_commands() in managment.__init__ does not look for commands in the top level directory. suppose things are set up as follows /project/ /app1/ /app2/ manage.p

Re: RequestContext + Auth.middleware 'Accesses the Session' (aka LazyUser ain't that lazy)

ser_id = request.session[SESSION_KEY] does the first session access then to user DB access says that in essence, it will never be lazy if using the auth context processor because it is always asked for, thus the LazyUser is just overhead in this case. and that happens before the messages are eve

Re: RequestContext + Auth.middleware 'Accesses the Session' (aka LazyUser ain't that lazy)

hat entire context_processors.auth() function a lazy entity so it only hits any session/DB/messages/etc,etc when 'called' from inside a template or view. bo On Oct 27, 6:58 pm, SmileyChris <[EMAIL PROTECTED]> wrote: > This is exactly why my patch in the session messages ticket [1] makes >

Re: RequestContext + Auth.middleware 'Accesses the Session' (aka LazyUser ain't that lazy)

to use the "request.user" instead of "user" directly in the Context and then require "django.core.context_processors.request" to always be included ... bo --~--~-~--~~~---~--~~ You received this message because you are subscribed to t

RequestContext + Auth.middleware 'Accesses the Session' (aka LazyUser ain't that lazy)

I'm not sure if this is 'supposed' to be the case or not so i'll ask i think i've seen a similar post like this before, but either a) i'm bad a search for it or b) it was only slightly related --- the issue --- using RequestContext(request, {}) + Auth.middleware always seems to access the sessi

Re: GET requests should not alter data?

ot; in the final query, and once you force it to the master (or it auto forces to the master) it will stay there for the duration of the request to deal with the asynchronous nature of a master-slave pair. bo On Oct 15, 12:50 am, "Amit Upadhyay" <[EMAIL PROTECTED]> wrote: > U

readlines + InMemoryUploadedFile

Hi Guys, Is there a reason why InMemoryUploadedFile does not proxy readlines as well from StringIO? seems like it should (especially if using PIL directly from the uploaded file) bo --~--~-~--~~~---~--~~ You received this message because you are subscribed to the

Re: threading, caching, and the yield in query.py

using the same data object churning out another template (or even the same template in a different stage). Which is why i find this strange. bo On Sep 29, 5:45 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Mon, 2008-09-29 at 10:37 -0700, bo wrote: > > > This little

threading, caching, and the yield in query.py

This little issue is really hard to replicate .. i've yet to find out how to programatically do it because it certainly revolves around a threading, object caching, and the Yield in Query.py (iteritems). I just wanted to post this here to see if anyone, with more experience then i, knows howto r