Re: Best place for code that processes stuff from settings.py once (for logging implementation)

On Tue, Oct 13, 2009 at 2:17 AM, Vinay Sajip wrote: > I know it was sloppy of me to call it "INSTALLED_APPS loading" as that > happens in db/models/loading.py - I thought it would be clear from my > saying I was talking about calling from Settings.__init__(). Ok... I

Re: Best place for code that processes stuff from settings.py once (for logging implementation)

> Maybe I'm oversimplifying this - and I'm sure if you'll tell me if I > am ;-) - but how about the following: add a setting called e.g. > SETUP_CALLBACKS  (or whatever name you prefer) which will be an > iterable (say, tuple) of callables which are called from > Settings.__init__ in the same way

Re: Adding signing (and signed cookies) to Django core

The lack of parallelism in terms of the interface is my biggest hangup here. I do think that this should find it's way into trunk, as signed cookies are important in the use cases you mention and are really easy to get wrong... and getting it wrong can be dangerous. I'm not going to get into

ANN: Django sprint in Washington DC area, August 1st

With 1.0 alpha upon us, I thought it would be a good time for an announcement. On August 1st, just under two weeks from now, we will be hosting a sprint in Washington, DC. The focus will be on Django 1.0 beta 1. This marks the first east-coast Django sprint (I think), so we're trying to bring

Re: API question for model saving

On Sun, May 4, 2008 at 7:02 PM, James Bennett <[EMAIL PROTECTED]> wrote: > The first is to look at the update() method that already exists on every > QuerySet and every default manager: this method *already* does one of > the things we want, namely force an UPDATE query to run. So, without >

Re: Cache Invalidation Proposal -- CachedModel

On Dec 7, 2007 6:07 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > > FWIW, I'm interested in this approach. > > I haven't had time to poke at the design, but wanted to at least give > some indication of interest since the thread's been quiet. Same here. I'm planning to look at this on Monday,

Re: Sul do Brasil

On 11/22/07, skywalkerbrz <[EMAIL PROTECTED]> wrote: > > Estou trabalhando num projeto web para uma empresa de desenvolvimento > de softwares de gestao. > Gostaria que programadores do sul do Brasil entrassem em contato pois > precisamos de uma alternativa ágil e eficiente de desenvolvimento de >

Re: Is Django support multiple date support ?

On 10/10/07, Milad <[EMAIL PROTECTED]> wrote: > > Hi, > Is Django support multiple date support ? > I want do something with Persian date I need some function. > I create it for myself but if exist a function which convert all > Django page without my hard code it would be so greate . Questions

Re: Adding a hook for pre-runtime setup (ticket #5685)

On 10/8/07, Mike Scott <[EMAIL PROTECTED]> wrote: > Can I throw a hat in the ring and suggest a post-send-request hook? Perhaps you mean `request_finished`? [0,1,2] - Ben [0] http://code.djangoproject.com/browser/django/trunk/django/core/signals.py#L2 [1]

Re: Adding a hook for pre-runtime setup (ticket #5685)

On 10/8/07, Paul Davis <[EMAIL PROTECTED]> wrote: > Something to think about though is providing a way to add > callbacks to this hook that is independant of settings.py. Having to modify settings.py doesn't both me here. It's done for middleware and context processors, so it seems to fit with

Re: Adding a hook for pre-runtime setup (ticket #5685)

On 10/8/07, Andrew Durdin <[EMAIL PROTECTED]> wrote: > Well, that looks like it'll be great for registering listeners (except > perhaps for pre/post_save/delete). I had overlooked the handling of these signals. They could arguably live in models.py if they are for the same application, but

Adding a hook for pre-runtime setup (ticket #5685)

Hello all, Yesterday I had posted an inquiry to django-users about how to make use of class_prepared. [0] Malcolm gave me a helpful reply, including a suggestion of adding a hook to allow pre-runtime setup to occur before executing a shell or request handler. I have opened a ticket and coded

Re: Django 100% threadsafe with DB?

On 9/25/07, Mike Scott <[EMAIL PROTECTED]> wrote: > It should be threadsafe - [... ] web applications [...] pretty much > [become] a threaded application Mike, There are two issues here. Thread safe and concurrent operation, and they are very different issues (though there is overlap). Django

Re: Many-to-many relationships with additional columns

Hello all, On 6/1/07, Marty Alchin <[EMAIL PROTECTED]> wrote: > So, there's a bit more to chew on; hopefully we can come up with some > final thoughts on this soon, because I'd love to see this happen. Marty's suggestion looks promising and seems to have a good bit of support from the core

Re: None != Null?

On 7/16/07, David Cramer <[EMAIL PROTECTED]> wrote: > > Is there a specific reason that myfield=None doesn't translate to > myfield__isnull=True in the database backend? Hi David, You may want to look here: http://code.djangoproject.com/ticket/1050 - Ben

Re: dojo onchange event

On 7/9/07, raha <[EMAIL PROTECTED]> wrote: > I have a dojo checkbox. I made it dynamically. > ... > Is there any body to help me? There probably is, but not here (this list is for development of Django (not Dojo)). You might want to try http://dojotoolkit.org/forum - Ben

Re: Django Week in Review -- ATTN: Adrian Holovaty

On 6/24/07, Clint Ecker <[EMAIL PROTECTED]> wrote: > > Let me know what you guys think of the tone, my wordiness, how I split up > the post into "random weblinks," changeset roundup, and SoC stuff, and > anything else that comes to mind. Hi Clint, The only correction/addition I have is that's

Re: Proposal: post_create signal

On 6/1/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > You're proposal (doing a database check and moving the "pre_save" > dispatch lower) has introduced an extra database query for every single > save, whether it's needed or not Two points here... First, there's already a database check for

Re: Proposal: post_create signal

On 6/1/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Let's ask the different question: what's the use case for a pre_create > signal that isn't already possible with pre_save? In my case it's a matter of enforcing privileges. Highly granular pirvileges can include "create" among other

Re: Proposal: post_create signal

On 6/1/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > You can't tell if it's an update without asking the database sometimes > (if the primary key value is not None). So pre_save can't make it > available unless the semantics of "pre_save" change so that it's no > longer prior to anything in

Newforms is_bound determination (was Re: Is it a bug: f.data = data return False instead of True ?)

On 6/1/07, olive <[EMAIL PROTECTED]> wrote: > This returns True: > f = myform(data) > f.is_valid() > > while this returns False: > f = myform() > f.data = data > f.is_valid() > > Is it a bug ? Not sure if it should be called a bug or not from a quick look at the source code

Re: Proposal: post_create signal

On 5/31/07, Ben Schwarze <[EMAIL PROTECTED]> wrote: > What about a simple additional attribute that wil be. This could be > fetched in listener functions (e.g. is_update=True/False)? > [...] > Any ideas about that? I like this idea... and it shouldn't pose any problem with backwards

Re: Proposal: post_create signal

On 6/1/07, Amit Upadhyay <[EMAIL PROTECTED]> wrote: > How about doing a: > > self.is_new = not bool(self.id) > > in pre_save and > > if self.is_new: # do something > > in post_save? Unfortunately, that won't work in the case of OneToOne models. They are required to have their primary key value

Re: Proposal: post_create signal

On 5/30/07, Robert Coup <[EMAIL PROTECTED]> wrote: > So the post_create signal would be triggered *after* the transaction was > committed? The patch in 2154 certainly doesn't handle that case. That's not what I was trying to communicate. It was mentioned that you won't know if "the save is

Re: Proposal: post_create signal

On 5/30/07, Robert Coup <[EMAIL PROTECTED]> wrote: > Why not connect to pre_save and check whether the primary key is None, > similar to the accepted way to check for creation if you override > Model.save()? Forest already mentioned not knowing if the object persistence will be successful. In

Re: Changeset [5231] -- do_clean_*() is awkward naming

On 5/14/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > I think we should try to stay with the "cleaning" line of thinking, > rather than validate- or normalise-related terms, just for consistency, > though. Agreed. What about clean_data -> cleaned_data and maintain clean_*() The biggest

Django's signal framework may register listeners more than once

Howdy folks, I was hacking around on a project, trying to use signals during model instantiation. I've used signals before, but came across an interesting 'wart' in the signals/dispatcher framework. The end result is that a listener can become registered with the dispatcher more than once...

Problem with syncdb's handling of ManyToManyFields

Howdy, folks, I'm in the process of migrating a Django project from MySQL to PostgreSQL and think I may have stumbled across a nasty bug. It relates to ManytoMany fields and the way in which syncdb creates the database tables to handle this. For full details, please see the ticket at:

Re: newsessions

On 3/14/07, James Bennett <[EMAIL PROTECTED]> wrote: > 1. Manually seeding the RNG with a value unique to the server process, > or to the request, would move the probability of key collision closer > to what it "should" be, thus dramatically reducing the problem. Do we really need to re-seed the

Re: newsessions

Man, there's been a lot of movement in this thread. I'd like to just throw out a few comments. 1) The current session framework unquestionably needs some attention. The way in which sessions are being generated isn't terribly efficient, and can certainly lead to collisions. 2) James has

Re: Ticket 3688 -- Improve support for mutually-referential models

Hi Russ, As Jeff has already said, this decision is understandable. I had found myself up against a wall when I created the solution... I figured it might be useful for other developers, but won't push for its inclusion in the base distribution. Further comments are below. On Mar 11, 6:20 pm,

Ticket 3688 -- Improve support for mutually-referential models

Howdy folks, I just created ticket #3688 [0]. It introduces a change we've been using internally for a few weeks and I thought might be useful to other users. Currently ForeignKey references can be to: * A class defined either in the current models.py or imported (via 'import') from another

Re: Have a look at django.newforms

Adrian, I think rassilon is talking about something like "help_text". I've seen this discussed before... both here and on django-users. As a result, I've created a patch that has been posted to trac. [1] -Ben [1] http://code.djangoproject.com/ticket/3255 On 1/8/07, Adrian Holovaty

Re: Re: Session security (was Re: Thinking out loud)

On 12/12/06, Rob Hudson <[EMAIL PROTECTED]> wrote: > > I agree that this would be a valuable addition. Perhaps you could > > submit a patch... if you're not comfortable doing that, perhaps > > someone else will. > > I'd be happy to attempt it. In looking at the code it seems like you > could

Re: Session security (was Re: Thinking out loud)

On 12/12/06, Rob Hudson <[EMAIL PROTECTED]> wrote: > > I remember reading many articles on PHP sessions and about session > hijacking, etc. Has Django's sessions been looked at from this > perspective or can Django's sessions have similar issues? Django does use an algorithm that generates

Re: Thinking out loud: move auth.Messages into the sessions app?

On 12/11/06, James Bennett <[EMAIL PROTECTED]> wrote: > Anyone have strong feelings one way or another? +1 (with caveat) Messages are valuable in both cases (per-user and per-session). I have an application that leaves messages for a user outside of a session context (a scheduled process runs

Re: DjangoPoweredSites wiki article vandalised, please revert

I can verify that this is indeed a problem and that Akismet does not allow normal users to revert the content. Version 442 seems to be an un-vandalised version (and is more recent thant 438) --Ben On 12/11/06, Matias Hermarud Fjeld <[EMAIL PROTECTED]> wrote: > > Hello. > >

Re: Re: Default representation of a Form

On 12/11/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > This is an interesting idea, but I think it's important to remember > the as_p(), as_table() and as_ul() shortcut methods are just > *shortcuts*. There's nothing stopping a developer from writing a > custom method on a Form, nor is there