On Fri, Mar 25, 2011 at 10:43 PM, Alex Gaynor wrote:
> There's http://code.djangoproject.com/ticket/3615, most of the effort there
> has been on making MySQL not be stupid though :) Someone at PyCon told me
> they found a way to make it work though (Chris Adams I think?).
I dunno -- almost every
On Fri, Mar 25, 2011 at 11:41 PM, Jacob Kaplan-Moss wrote:
> On Fri, Mar 25, 2011 at 6:45 PM, maxi wrote:
> > Yes, that seems to be the problem. Firebird doesn't support deferred
> > constraints.
> > Are there any approach or workaround to solve this ?
>
> No workarounds, no. We need to refactor
On Fri, Mar 25, 2011 at 6:45 PM, maxi wrote:
> Yes, that seems to be the problem. Firebird doesn't support deferred
> constraints.
> Are there any approach or workaround to solve this ?
No workarounds, no. We need to refactor our test suite to not rely on
deferred constraints (except of course wh
On Friday, March 25, 2011 11:43:39 PM UTC+11, Pascal Germroth wrote:
>
> On Fri, 2011-03-25 at 12:55 +0100, Łukasz Rekucki wrote:
> > On 25 March 2011 12:34, Thomas Guettler wrote:
> > > I look at your example code. You need to name the webserver in the
> > > code. That's not very nice. I guess
On 25 mar, 20:22, Alex Gaynor wrote:
> On Fri, Mar 25, 2011 at 7:20 PM, maxi wrote:
> > On 25 mar, 19:21, Gabriel Hurley wrote:
> > > The extra object is in the initial_data.json fixture which is loaded
> > > automatically. If you're not seeing that object than something is wrong
> > with
> >
On Fri, Mar 25, 2011 at 7:20 PM, maxi wrote:
> On 25 mar, 19:21, Gabriel Hurley wrote:
> > The extra object is in the initial_data.json fixture which is loaded
> > automatically. If you're not seeing that object than something is wrong
> with
> > your initial_data fixture loading.
> >
> > -
On 25 mar, 19:21, Gabriel Hurley wrote:
> The extra object is in the initial_data.json fixture which is loaded
> automatically. If you're not seeing that object than something is wrong with
> your initial_data fixture loading.
>
> - Gabriel
Hi Gabriel,
Thank for response.
I see now what I ha
The extra object is in the initial_data.json fixture which is loaded
automatically. If you're not seeing that object than something is wrong with
your initial_data fixture loading.
- Gabriel
--
You received this message because you are subscribed to the Google Groups
"Django developers" g
On 25 mar, 16:44, Paul McMillan wrote:
> We can't help you if you don't tell us a bit more about your system.
> What version of Python? What OS?
I'm running django 1.3 from trunk. I'm using Ubuntu 10.04 and python
2.6.5
>Is there anything else unusual about
> your system or how you are running t
We can't help you if you don't tell us a bit more about your system.
What version of Python? What OS? Is there anything else unusual about
your system or how you are running the tests?
-Paul
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
Hi,
I've running (or trying) the django 1.3 test suite and I've got an
error with the next traceback...
Traceback (most recent call last):
File "/home/maxi/projects/django/django/tests/modeltests/fixtures/
tests.py", line 221, in test_compress_format_loading
''
File "/home/maxi/projects/d
Wow, I got a lot more responses to this than I'd thought, so I'd say
I'm well on my way here. Thanks so much everyone -- y'all rock.
Jacob
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develope
That's also already done, check
https://github.com/django-extensions/django-extensions/blob/master/django_extensions/management/commands/show_urls.py,
it can be easily converted to JSON (I have a branch that does it, but
it's not up-to-date).
I also have the urls module in JavaScript already, but
On 25.03.2011 12:55, Łukasz Rekucki wrote:
> On 25 March 2011 12:34, Thomas Guettler wrote:
>> Hi,
>>
>> I look at your example code. You need to name the webserver in the
>> code. That's not very nice. I guess it should be possible to
>> guess the webserver (apache vs nginx) by looking at reques
On Fri, 2011-03-25 at 12:55 +0100, Łukasz Rekucki wrote:
> On 25 March 2011 12:34, Thomas Guettler wrote:
> > I look at your example code. You need to name the webserver in the
> > code. That's not very nice. I guess it should be possible to
> > guess the webserver (apache vs nginx) by looking at
On 25 March 2011 12:34, Thomas Guettler wrote:
> Hi,
>
> I look at your example code. You need to name the webserver in the
> code. That's not very nice. I guess it should be possible to
> guess the webserver (apache vs nginx) by looking at request.META.
>
-1 on guessing anything, especially some
Hi,
I look at your example code. You need to name the webserver in the
code. That's not very nice. I guess it should be possible to
guess the webserver (apache vs nginx) by looking at request.META.
Documentation would be nice
Thomas
On 25.03.2011 10:23, Gustavo Narea wrote:
> Hi all,
>
>
Hey All,
This is somewhat related to the ticket “Process HTTP PUT into
request.FILES and request.PUT as done for POST” [1], although much broader
in scope.
In that ticket there’s a link to a related discussion [2] where Malcolm
Tredinnick explains why a request.PUT that mirrors the current
Hi Russ,
Thanks for the long reply and all the suggestions. My comments are
inline.
> What if you need to support both? e.g.,
>
>
> the bar value
>
>
> It seems to me that you would be better served providing a way to
> annotate each individual metadata value as (and I'm bikeshedding a
> nam
Hi all,
Just to let you know that there's an X-Sendfile implementation for
WSGI apps (inc. Django), which also works with Nginx:
https://launchpad.net/wsgi-xsendfile
You can use it in Django views via twod.wsgi. For example:
"""
from twod.wsgi import call_wsgi_app
from xsendfile import NginxSend
20 matches
Mail list logo