Ivan Sagalaev wrote:
> When it comes to overhead... As far as I know PostgreSQL in autocommit
> mode will wrap each statement (even SELECT) in an implicit transaction.
>
> http://it.toolbox.com/blogs/database-soup/postgresql-application-performance-tips-part-1-13172
...
> So what Django does now .
Malcolm Tredinnick wrote:
> As I mentioned to Collin at the code sprint in Portland, I think it'd be
> a good idea to make sure we expose the ability to turn on auto-commit,
> but I don't really like making it the default. In any case, providing
> the ability that's can be controlled via, for exam
On Sun, 2008-09-21 at 11:32 -0700, Richard Davies wrote:
[...]
> I suspect that this will significantly simplify the Django codebase
> vs.
> trying to simulate both auto-commit and transaction behaviors on top
> of a transactional connection - it would certainly remove most of the
> mechanisms i
Richard Davies wrote:
> On the first question, I'd suspect that many pages of many (simple)
> web applications just have a one-to-one mapping between the web page
> and a single line of SQL on a normalized database - e.g. a page
> listing all events (single SELECT), a page listing all people at an
> > It is also highly inefficient for Web applications (since
> > they most often do nothing transactional) and gets you into trouble in
> > error cases.
>
> I don't want to get into the argument about ticket 3460 itself but I
> just don't get this paragraph... What is special in web applications
> One reason not to do this is that it simply isn't standard behaviour for
> Python database adaptors (they must be in non-autocommit mode
> initially). So there's a principle of least-surprise thing going on.
I'm not convinced by the argument of least-surprise. As you said,
there
are explicit co
[EMAIL PROTECTED] wrote:
> It is also highly inefficient for Web applications (since
> they most often do nothing transactional) and gets you into trouble in
> error cases.
I don't want to get into the argument about ticket 3460 itself but I
just don't get this paragraph... What is special in we
On 17 sep, 02:14, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> On Mon, 2008-09-15 at 14:10 -0700, Ken Arnold wrote:
> > I previously brought up a URL resolution refactoring (http://
> > groups.google.com/group/django-developers/browse_thread/thread/
> > e16bcd24f9e27062/a84b8e58fe2e7786), and w
On Sep 15, 8:50 am, "Eduardo O. Padoan" <[EMAIL PROTECTED]>
wrote:
> On Mon, Sep 15, 2008 at 9:39 AM, Julien Phalip <[EMAIL PROTECTED]> wrote:
> > That's a good point. Mixing {% include %} and {% with %} is both more
> > verbose and less flexible than if using a custom tag. In this case,
> > using
> I believe this boils down to the same issue as ticket [3460] - both
> the psycopg1 and psycopg2 backends are using the wrong isolation
> level, as a result of which the Django SQL is wrapped by psycopg
> inside an implicit transaction. I have tried using the [3460] patch,
> which gives me the Po
Am 19.09.2008 um 18:08 schrieb Armin Ronacher:
[snip]
>
> What's harder to fix is how the i18n integration translates filter
> arguments or gettext constants (those _("foo") thingies). Currently
> that happens very often at node/object creation rather than node/
> object evaluation. A good exam
kubiku wrote:
> May I suggest using word "stable" instead of final? While "final" is
> great mood improver for internal django developers, "stable" gives
> stronger message to django users and especially their bosses. And
> brings more assurance that it means what it means. Final is, well,
> some
On Sep 17, 5:25 am, "James Bennett" <[EMAIL PROTECTED]> wrote:
> * For the final 1.1 release: (1, 1, 0, 'final', 0).
May I suggest using word "stable" instead of final? While "final" is
great mood improver for internal django developers, "stable" gives
stronger message to django users and especia
Hi Guys,
I wasn't sure where/who to get in touch with regarding this but I was hoping
that on both the djangocon and django blog websites announcements could be
made to the effect of announcing the availability of the djangocon videos
from google now on youtube. I think it would be great to let ev
On Fri, 2008-09-19 at 23:47 -0700, Richard Davies wrote:
> Hi Jacob,
>
> I agree that this is documented behavior for PostgreSQL
> _transactions_.
>
> The reason that I think it's a bug is that I shouldn't be in a
> transaction at all - as I understand
> http://docs.djangoproject.com/en/dev/to
15 matches
Mail list logo
