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
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
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
> > 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
[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
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
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,
> >
> 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
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
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,
>
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
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
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
>
On Sat, Sep 20, 2008 at 6:13 PM, HenrikV <[EMAIL PROTECTED]> wrote:
>
> I am working on #3011, making the User model overridable.
Ok - do you think this might have been useful information to include
on your original query?
> I have a
> working patch, but
> if I set the db_table on the User
16 matches
Mail list logo
