Re: redundant SQL's in Django tutorial

2009-12-01 Thread stargazer 
And here is the Postgresql log file for the same "polls" screens.
Same select as in debug_toolbar

It seems, such thing like a connection pool does not exists by default
(every time connection is initialized)
Is it just a setting in Django or in the psycopg2 ?

**
LOG:  statement: SET DATESTYLE TO 'ISO'
LOG:  statement: SHOW client_encoding
LOG:  statement: SHOW default_transaction_isolation
LOG:  statement: BEGIN; SET TRANSACTION ISOLATION LEVEL READ COMMITTED
LOG:  statement: SET TIME ZONE E'Europe/Berlin'
LOG:  statement: SELECT version()
LOG:  statement: SELECT "polls_poll"."id", "polls_poll"."question",
"polls_poll"."pub_date" FROM "polls_poll"
LOG:  statement: ROLLBACK
LOG:  statement: SET DATESTYLE TO 'ISO'
LOG:  statement: SHOW client_encoding
LOG:  statement: SHOW default_transaction_isolation
LOG:  statement: BEGIN; SET TRANSACTION ISOLATION LEVEL READ COMMITTED
LOG:  statement: SET TIME ZONE E'Europe/Berlin'
LOG:  statement: SELECT "polls_poll"."id", "polls_poll"."question",
"polls_poll"."pub_date" FROM "polls_poll" WHERE "polls_poll"."id" = 2
LOG:  statement: SELECT "polls_choice"."id", "polls_choice"."poll_id",
"polls_choice"."choice", "polls_choice"."votes" FROM "polls_choice"
WHERE "polls_choice"."poll_id" = 2
LOG:  statement: ROLLBACK
LOG:  statement: SET DATESTYLE TO 'ISO'
LOG:  statement: SHOW client_encoding
LOG:  statement: SHOW default_transaction_isolation
LOG:  statement: BEGIN; SET TRANSACTION ISOLATION LEVEL READ COMMITTED
LOG:  statement: SET TIME ZONE E'Europe/Berlin'
LOG:  statement: SELECT "polls_poll"."id", "polls_poll"."question",
"polls_poll"."pub_date" FROM "polls_poll" WHERE "polls_poll"."id" = 2
LOG:  statement: SELECT "polls_choice"."id", "polls_choice"."poll_id",
"polls_choice"."choice", "polls_choice"."votes" FROM "polls_choice"
WHERE ("polls_choice"."poll_id" = 2  AND "polls_choice"."id" = 10 )
LOG:  statement: SELECT (1) AS "a" FROM "polls_choice" WHERE
"polls_choice"."id" = 10
LOG:  statement: UPDATE "polls_choice" SET "poll_id" = 2, "choice" =
E'choice2', "votes" = 31 WHERE "polls_choice"."id" = 10
LOG:  statement: COMMIT
LOG:  statement: SET DATESTYLE TO 'ISO'
LOG:  statement: SHOW client_encoding
LOG:  statement: SHOW default_transaction_isolation
LOG:  statement: BEGIN; SET TRANSACTION ISOLATION LEVEL READ COMMITTED
LOG:  statement: SET TIME ZONE E'Europe/Berlin'
LOG:  statement: SELECT "polls_poll"."id", "polls_poll"."question",
"polls_poll"."pub_date" FROM "polls_poll" WHERE "polls_poll"."id" = 2
LOG:  statement: SELECT "polls_choice"."id", "polls_choice"."poll_id",
"polls_choice"."choice", "polls_choice"."votes" FROM "polls_choice"
WHERE "polls_choice"."poll_id" = 2
LOG:  statement: ROLLBACK
**

--

You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: redundant SQL's in Django tutorial

2009-12-01 Thread stargazer 
> Caching isn't the issue here, it's a matter of writing the queries
> properly. Yes, select_related will help.
Well, I tried select_related but without success.
It would be good to see an example...

--

You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: redundant SQL's in Django tutorial

2009-12-01 Thread Daniel Roseman 
On Dec 1, 1:57 pm, stargazer  wrote:
> Hi all,
>
> I'm trying the famous Django 
> tutorial:http://docs.djangoproject.com/en/1.1/intro/
>
> Playing with "polls" and "choices" I see lot of SQL queries this
> application creates. Actually, I just selected a list of polls
> than selected the poll with ID=2, than voted for a choice.
> Here are details (SQL's recorded using "debug_toolbar", may be a
> database log will show something else):

> It seems, same records are selected several time.
> With some sort of caching this could be greatly improved.
>
> May be some built-in Django tools (like select_related()? )  can help
> here?
>
> I now, number of cache implementations exists
> (like thishttp://github.com/mmalone/django-caching/ and 
> thishttp://github.com/dcramer/django-orm-cache)
> but I would like to use built-in Django instruments first.


Caching isn't the issue here, it's a matter of writing the queries
properly. Yes, select_related will help.

But you can't expect the tutorial to explain these concepts - it's
supposed to be a very basic introduction to using Django, and doesn't
go into detail. The full explanation of how to make queries is in the
actual documentation.
--
DR.

--

You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.