Re: natural keys and dumpdata

Hi Chris, you're not 100% correct with this statement: 370 When ``use_natural_keys=True`` is specified, the primary key is no longer 371 provided in the serialized data of this object since it can be calculated 372 during deserialization:: since in other old

Re: natural keys and dumpdata

On Jul 10, 1:47 am, Stijn Hoop wrote: > Hi, > > I am trying to use the 'natural keys' feature of django to make a sort > of "future proof" fixture loading possible. > [...] > With the patch linked below[1] I have successfully used dumpdata and > loaddata for a .json export of my

Regression problem on admin date format

Hello, Have anybody (Marc Garcia ?) check http://code.djangoproject.com/ticket/13621 ticket. It explains a bug concerning date and time formats. The admin does not conform the i18n locale settings on displaying time and date formats and reverts to the default format. It seems a true regression

Re: LOGIN_URL, LOGOUT_URL, LOGIN_REDIRECT_URL and SCRIPT_NAME.

On Jul 7, 7:11 pm, Graham Dumpleton wrote: [snip] > web application, to be a well behaved WSGI citizen, should honour > SCRIPT_NAME setting as supplied by the server, and ensure that ways > are provided such that everything in the users code, including > configuration,

Re: LOGIN_URL, LOGOUT_URL, LOGIN_REDIRECT_URL and SCRIPT_NAME.

Tom, HTTP_HOST and other don't solve the multiple-host deployment, and it is a solution you can do by yourself if you need. I'd like to see better solution: ability to make reverse work for such URLs. I think, currently the problem is in the binding time: The load order is typically the

Re: Proposal: {% include_partial %} template tag

Hi Jonathan, I don't believe you really need that complicated structure: extends -> includes -> extends. If I were you and had this problem, I'd rewrite it to something more simple. However, you can use {% block %} with my http://github.com/buriy/django-containers : :: file.html :: {% render

Re: New admin feature: Delete and replace with existing object

i'll reply one by one * What if you have multiple models referring to Author? Do you assume that every related model will be updated the same way? * What if you have multiple foreign keys from Blog to Author? Do you assume that every foreign key on a single model will be updated in the same

Re: natural keys and dumpdata

On Fri, Jul 9, 2010 at 8:47 AM, Stijn Hoop wrote: > This is rather impossible without natural keys, for I cannot know the > maximum ID of any primary key of tables that they have added data to. > However with natural keys I can do away with recording the numerical > ID of an

Re: Comet support in Django?

On 9 July 2010 13:25, Yuval Adam wrote: > But what is the easiest way to do this? Shouldn't Django supply some > wrapper for comet functionality? > I imagine this is really out of the scope of Django but I might be missing something. I'm no expert and haven't done much more

natural keys and dumpdata

Hi, I am trying to use the 'natural keys' feature of django to make a sort of "future proof" fixture loading possible. By "future proof" I mean that I want a site administrator to be able to add new objects to database tables where I will provide initial data. But I also want to be able to add

Re: Proposal: {% include_partial %} template tag

Something related, that we could really use is passing not just variables to the include, but also blocks. I tried to implement a template tag for this, but it doesn't work together with how Django replaces blocks in the extended template at compile time instead of during the renderering. I would

Comet support in Django?

Hi guys. I failed to find any serious documentation on how to do comet (AKA HTTP push) on Django. Obviously Django does not (and will not?) support this out-of-the-box due to the way Django is deployed, and naturally you will need to use an external server (orbited and twisted come to mind).

Re: LOGIN_URL, LOGOUT_URL, LOGIN_REDIRECT_URL and SCRIPT_NAME.

On Thu, Jul 8, 2010 at 3:40 PM, Russell Keith-Magee wrote: > Personally, I see this as a case of explicit vs implicit. > > As currently defined, LOGIN_URL points to the login URL. Period. > > Under the proposed patch, the onus is on every possible script to > ensure that

Re: Problem with randrange in django/middleware/csrf.py

After all it was a misconfiguration of my system and not a problem of Python or Django. Somehow the special files /dev/random and /dev/urandom got screwed up. I suppose it was the outcome of a bad update of the udev package on my Archlinux system. When I recreated the node of /dev/urandom