s a
> pointless change; by reading 2, it's a backwards incompatible change.
doesn't all this backward compatibility and nullables and deletions of
related objects get solved by something mentioned in
http://code.djangoproject.com/ticket/8168
(i know it's yet another signal) but it would seem to
ll 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 breaking the api as it
stands now (where i'm sure some fol
custom
subclass for each App and things would get messy fast)
just a thought.
bo
On Dec 10, 6:25 am, AcidTonic <acidto...@gmail.com> wrote:
> Currently the cascading delete functionality requires many users to
> change how their app works slightly to accommodate this "feat
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
very 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 this area would be to remov
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
On Nov
if 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
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@googlegroups.com
To unsubscribe from this group,
uess 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.
I'm sure the commands are rarely overloaded or even too far messed
with (the documentation says to look a
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/
equest.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 even consider
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
> the mess
se 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 the
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
ELECT" 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
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
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 is
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
18 matches
Mail list logo
