Hey all,
This has been a productive week for multiple database support in Django.
Firstly I got all my original work into Django's SVN repository, in
more-or-less atomic commits (they weren't perfect, but unfortunately most of
the early work was anything but linear). Secondly all tests are now pa
Relates to HTTP/CGI requirements. See discussion:
http://groups.google.com/group/python-web-sig/browse_frm/thread/2003e1c1ecce27b2
Graham
On Jun 6, 12:21 am, crypto wrote:
> Why is Django unquoting the path_info in WSGIRequestHandler?
>
> http://example.com/http%3A%2F%2Ftest.org%2Fvocab%23FO
If you read my GSoC Status update (http://groups.google.com/group/
django-developers/t/3b9147615e36e1a3 ), some of this is already in
there.
The main idea of ticket 10190 is to provide an option for users to
give a specific charset for an HttpResponse. The charset and encoding
should be the same
I spent a good amount of time working to synthesize the requirements
and work already done for ticket 2131 (which is to provide
HttpResponseSendFile with server-specific headers as well as a
fallback for servers without specific optimizations). I still have a
bit of confusion that I may enumerate
Hi
On 5 Cze, 22:39, Ian Kelly wrote:
> We could add keys to the DATABASE_OPTIONS setting that would cause
> this to be set. I would be concerned about allowing NLS_TERRITORY to
> be changed in this manner unless we also implement a different
> solution for the weekday inconsistency.
The NLS_TE
On Fri, Jun 5, 2009 at 2:05 PM, Antoni Aloy wrote:
> I think in your case is quite the same, take a look at
> http://www.oracle.com/technology/tech/globalization/htdocs/nls_lang%20faq.htm
> and the set the enviornment variable NLS_LANG on your application. In
> the setting perhaps.
This won't wor
On Fri, Jun 5, 2009 at 1:29 PM, slafs wrote:
> another thing is that I don't understand why NLS_TERRITORY has to be
> set to 'AMERICA'.
Because the region determines how the days of the week are numbered.
I have no idea what mapping POLAND uses, but if it's different from
AMERICA, then expect to
2009/6/5 slafs :
>
> Hi there!
>
> It's my first message here so forgive any mistakes. I don't know even
> if I should write about this here.
> Anyway...
> I was having a problem with proper (polish) ordering of my queries
> within a queryset from an Oracle backend.
>
Recently we had some weird pr
Hi there!
It's my first message here so forgive any mistakes. I don't know even
if I should write about this here.
Anyway...
I was having a problem with proper (polish) ordering of my queries
within a queryset from an Oracle backend.
(check
http://groups.google.com/group/django-users/browse_thre
A quick update, I have coverage support almost ready for review (and
compatible with the latest coverage, utilizing its reporting system). I have
started work on test-only models in a new branch on github
(local/gsoc_models) until we agree on the coverage stuff, then I'll merge
that in. About to ta
2009/6/5 crypto :
> Why is Django unquoting the path_info in WSGIRequestHandler?
Because that's what the WSGI spec says to do. More precisely, the
WSGI spec doesn't say anything specific about it, but defers to the
CGI spec, which is basically rfc3875, which says (in section 4.1.5):
Unlike a
Why is Django unquoting the path_info in WSGIRequestHandler?
http://example.com/http%3A%2F%2Ftest.org%2Fvocab%23FOAF/
becomes:
http://example.com/http://test.org/vocab#FOAF/
which is an invalid url.
Is this an oversight or is there something in the HTTP spec that says
otherwise?
file: django
Thanks again Graham ...
I see your point now ...
I'll try to trace further down, and try to "go all the way up" to the
xhaus modjy-servlet.
I will also try to compare to compare WSGI-bahaviour under Cpython and
my setup (Jython/Geronimo ...)
I will then also file a more detailed bug-report, tr
On Jun 5, 8:09 pm, "evert_car...@yahoo.co.uk"
wrote:
> Thanks Graham.
>
> I'll have a look at the bug-tracking system later on. As mentioned
> above, I do have other things on my mind right now.
>
> I don't think WSGI is at fault.
>
> The data is available after all, it is not truncated at all.
Thanks Graham.
I'll have a look at the bug-tracking system later on. As mentioned
above, I do have other things on my mind right now.
I don't think WSGI is at fault.
The data is available after all, it is not truncated at all. In other
words, WSGI correctly "hands-over" all the data to Django.
15 matches
Mail list logo