> I don't see a strong reason to support PyGreSQL (or any PostgreSQL
> Python driver other than psycopg) -- psycopg is free to download and
> use, and installing it does not require root access to a server. Which
> problems did you have with psycopg?
>
>
I was not able to compile it on the s
On 11/14/06 6:41 PM, shaunc wrote:
> One reason (in my opinion) for an effort on a server would be to use
> non-blocking i/o. You'd want to also use non-blocking i/o on the
> database side as well. Has anyone thought about that for django?
Maybe I'm being dense here, but I don't really understand
On 11/14/06, Rapheal Kaplan <[EMAIL PROTECTED]> wrote:
> Django comes with support for the psycopg Python DB drivers. I was
> interested to see if it could support the PyGreSQL (the pgdb package) for
> systems that would not have access to psycopg. Is anyone else interested in
> this?
>
> I
I stumbled across this ticket with patch a couple months ago. I
thought of it recently and wanted to bring it to the attention of the
developers. I like the idea and it looks like it simplifies the
edit_line stuff a lot...
http://code.djangoproject.com/ticket/2248
--~--~-~--~~
One reason (in my opinion) for an effort on a server would be to use
non-blocking i/o. You'd want to also use non-blocking i/o on the
database side as well. Has anyone thought about that for django?
--~--~-~--~~~---~--~~
You received this message because you are
Django comes with support for the psycopg Python DB drivers. I was
interested to see if it could support the PyGreSQL (the pgdb package) for
systems that would not have access to psycopg. Is anyone else interested in
this?
I have thus far managed to get it to work by copying the psycopg b
"__getitem__" in
django.forms.__init__.RadioSelectField.render.RadioFieldRenderer
In this inner class (line 546), I have found it useful to have:
def __getitem__( self, item ):
return self.datalist[ item ]
Then I can put some commentary (say) in the html, and explici
James Bennett a écrit :
> On 11/14/06, James Bennett <[EMAIL PROTECTED]> wrote:
> > IIRC I'm the one who made it do that, and it was because, at the time,
> > the way Django handled the 'range' lookup was *not* inclusive, so it
> > needed to extend to the first day of the next month or else it
>
My $0.02:
The main reason why you see things like Mongrel popping up for Rails,
IMHO, is that the concept of doing serious web development in Ruby is
still fairly new; until Rails popped up, nobody really did much with
it (mod_ruby, for example, seems to be abandonware). Thus, the problem
of "wha
I'm using fastcgi with Apache2, but it's a customer-only site with low
traffic. I've had absolutely no problems on the productive systems.
Though, sometimes restarting the daemons on the testing system during an
update fails. It's seldom, and I'd rather blame my start/stop scripts.
My reasons for
On 11/14/06, James Bennett <[EMAIL PROTECTED]> wrote:
> IIRC I'm the one who made it do that, and it was because, at the time,
> the way Django handled the 'range' lookup was *not* inclusive, so it
> needed to extend to the first day of the next month or else it
> wouldn't be able to find objects
On 11/14/06, Jean-Luc <[EMAIL PROTECTED]> wrote:
> last_day is the first day of next month
>
> 130 lookup_kwargs = {'%s__range' % date_field: (first_day,
> last_day)}
>
> range is inclusive
IIRC I'm the one who made it do that, and it was because, at the time,
the way Django handled the '
On 11/14/06 10:17 AM, Ivan Sagalaev wrote:
> Jacob, do you have any links to read on the subject or your own
> thoughts? I'm asking because I wonder if Django running in an external
> FCGI server would also scale worse then under mod_python... From the top
> of my head I can't imagine why it wo
Jacob Kaplan-Moss wrote:
> RoR has a performance and scalability problem that FCGI makes worse,
Jacob, do you have any links to read on the subject or your own
thoughts? I'm asking because I wonder if Django running in an external
FCGI server would also scale worse then under mod_python... From
On 11/14/06 6:23 AM, comechao wrote:
> Why not create a server like mongrel for Django?
Go for it - we'll wait...
No, seriously -- the main reason is that Django doesn't need it. Django under
mod_python is crazy fast and super stable, and so it doesn't need a "special"
deployment setup just f
Why not create a server like mongrel for Django?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe fro
comechao,
What would be the advantage over mod_python in Apache ?
Graham.
comechao wrote:
> Why not create a server like mongrel for Django?
>
>
> >
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Dj
I have an idea. Instead of a 'message' parameter, there could be a
on_success, on_error callable parameter in the function. I don't know
what the parameters to the callback would be, but this is the rough
idea:
def on_error(request, ?other parameters?):
request.session['message] = "Not saved
Hi Django boys and girls
Please see my post "Date based generic view"
in Django users
I check the code in
root/django/trunk/django/views/generic/date_based.py
124 # Calculate first and last day of month, for use in a
date-range lookup.
125 first_day = date.replace(day=1)
126
Dear Adrian, Malcolm, and other django core developers,
> > When you create a model, you could add translatable=True to fields
> > that have to be in the language-specific table.
> > When you make selections, you would need to set the language name in
> > the following or a similar way:
> > MyMod
On 11/14/06, Gary Wilson <[EMAIL PROTECTED]> wrote:
> Curious, does the new testing setup contain any mechanism for running
> tests for my own applications, say in a package /tests instead
> of in modeltests/ or regressiontests/ ?
Yes. There is preliminar documentation for the new testing framewo
http://translator-service.blogspot.com/
serve for everyone...yes
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
T
Ivan Sagalaev wrote:
>> What about using generic relations for this?
>
> +1. Keeping all translations in one table instead of creating separate
> tables for each user table is what I was going to propose but you beat
> me :-)
On a second thought I think it has certain problems (well, anything
23 matches
Mail list logo
