and
streams back the output accordingly.
The CGI script could extract the location of the file and validate the
permissions from one or more encrypted parameters passed to it, or it
could do a database lookup on its own.
Istvan
--~--~-~--~~~---~--~~
You recei
On Feb 7, 10:58 pm, "Derek Lee-Wo" <[EMAIL PROTECTED]> wrote:
> My app does a bunch of database queries and processing and when I
> timed that part, it all completes within 0.5 seconds, but the call to
> render_to_response() takes 18 seconds. Needless to say, the end-user
> experience isn't
Joe wrote:
However, as little as 5000 hits a day brings my site down to a crawl
during peak hours! The funny thing is, I have plenty of free ram space
and processor during these peak hours.
Something must be wrong with the setup. Unless all of these users come
in the during the same minute.
I have not yet used Tramline with Django I am expecting to do so in
case I need to rewrite a Zope application. I have had good experience
using JUpload (again with Zope not Django).
It might be that one needs to deploy the Tramline on a separate mod
python handler not the one Django is running
Jeffrey Zelt wrote:
> The Django ORM is probably the only piece of Django I am embarrassed
> showing other developers.
Oh really?
> I will not be satisfied if the current ORM is capable of fulfilling 95%
> requirements
You must be inexperienced if you think that an elegant solution to 95%
of
Paul Childs wrote:
> I'm pretty sure that the download script that I found here...
> http://code.djangoproject.com/ticket/1327
> must not be doing the job properly.
if you are using windows you'll need to change line 41 to:
fp = open(basedir + link, 'wb+')
i.
Adrian Holovaty wrote:
> I have never seen anything like that. I suspect the images are
> corrupted somehow, and I have no idea how that might have happened.
One common cause is opening files in text mode under windows. The flags
need to be 'wb' not just 'w'
i.
> Can anyone comment on the upload limitations of Django?
alas the situation is hopeless,
the fix itself is very simple, unfortunately the patch that was
supposed to add this
http://code.djangoproject.com/ticket/2070
has degenerated into adding a completely unrelated feature (progress
Fredrik Lundh wrote:
> that's probably because they're scientists, and have a pretty good
> understanding of basic math
I think the main reason might be that when they get it wrong they don't
have to pay the difference from their own pocket.
i.
Looks nice Leon, congratulations.
You might want to try to tweak the spacing to allow for a little more
text per page ... and allow for the latest news to be read without
having to scroll the page
just an opinion,
i.
--~--~-~--~~~---~--~~
You received this
There is an option to manage.py
--adminmedia=ADMIN_MEDIA_PATH
that might just do what you need.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to
Russell Keith-Magee wrote:
>
> I'm sure it could, but I'm almost certain it wont.
The only problem with this is that some kind of sites cannot be tested
with the development server.
If the site streams back the output and incrementally builds it then it
cannot for example read in the css even
> I am expecting an answer like: "You are crazy: db native searches will always
> be faster"
You are crazy: swish-e searches will always be faster.
Swish-e was created for indexing/searching documents. The only issue at
hand is whether the speedup you get is worth the trouble of having to
In your listing line 24 is not aligned properly.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this
> Other reason? Because this option exist!
It does not.
Lighttpd fastcgi does not work on windows.
i.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to
Congrats!
And while I'm at it I'll say this: Django is the real deal.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To
great, thanks for the tip
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
In Django 0.91 the
foos.get_count( complex=condition )
was a valid construct. The magic removal branch raises an exception:
"count() takes exactly 1 argument (2 given)" when doing a :
foo.objects.count( condition )
Is that intended? What would be a workaround?
i.
Great patch Ivan,
This issue is of great importance as it is one of those oversights that
separates a "cool toy" from a reliable "work horse".
Istvan
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google G
Opened a ticket on it and it looks like it is being patched to the
behavior that I mentioned above. Very nice!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email
> I think the question Istvan was asking was whether files are stored in
> memory until they are written out as a single entity to the destination
> file. And I believe this is correct: Django does not stream the incoming
> content to the file as it receives it,
Yes, that is what
I'm evaluating Django for an application in wich we need to process
uploaded files of various sizes (potentially quite large).
>From the docs it looks like uploaded files will kept in memory instead
of being streamed into (temporary) files. Is that the case?
22 matches
Mail list logo
