sqlobject-cvs Mailing List for SQLObject (Page 35)
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
(9) |
Apr
(74) |
May
(29) |
Jun
(16) |
Jul
(28) |
Aug
(10) |
Sep
(57) |
Oct
(9) |
Nov
(29) |
Dec
(12) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(7) |
Feb
(14) |
Mar
(6) |
Apr
(3) |
May
(12) |
Jun
(34) |
Jul
(9) |
Aug
(29) |
Sep
(22) |
Oct
(2) |
Nov
(15) |
Dec
(52) |
2005 |
Jan
(47) |
Feb
(78) |
Mar
(14) |
Apr
(35) |
May
(33) |
Jun
(16) |
Jul
(26) |
Aug
(63) |
Sep
(40) |
Oct
(96) |
Nov
(96) |
Dec
(123) |
2006 |
Jan
(159) |
Feb
(144) |
Mar
(64) |
Apr
(31) |
May
(88) |
Jun
(48) |
Jul
(16) |
Aug
(64) |
Sep
(87) |
Oct
(92) |
Nov
(56) |
Dec
(76) |
2007 |
Jan
(94) |
Feb
(103) |
Mar
(126) |
Apr
(123) |
May
(85) |
Jun
(11) |
Jul
(130) |
Aug
(47) |
Sep
(65) |
Oct
(70) |
Nov
(12) |
Dec
(11) |
2008 |
Jan
(30) |
Feb
(55) |
Mar
(88) |
Apr
(20) |
May
(50) |
Jun
|
Jul
(38) |
Aug
(1) |
Sep
(9) |
Oct
(5) |
Nov
(6) |
Dec
(39) |
2009 |
Jan
(8) |
Feb
(16) |
Mar
(3) |
Apr
(33) |
May
(44) |
Jun
(1) |
Jul
(10) |
Aug
(33) |
Sep
(74) |
Oct
(22) |
Nov
|
Dec
(15) |
2010 |
Jan
(28) |
Feb
(22) |
Mar
(46) |
Apr
(29) |
May
(1) |
Jun
(1) |
Jul
(27) |
Aug
(8) |
Sep
(5) |
Oct
(33) |
Nov
(24) |
Dec
(41) |
2011 |
Jan
(4) |
Feb
(12) |
Mar
(35) |
Apr
(29) |
May
(19) |
Jun
(16) |
Jul
(32) |
Aug
(25) |
Sep
(5) |
Oct
(11) |
Nov
(21) |
Dec
(12) |
2012 |
Jan
(3) |
Feb
(4) |
Mar
(20) |
Apr
(4) |
May
(25) |
Jun
(13) |
Jul
|
Aug
|
Sep
(2) |
Oct
(25) |
Nov
(9) |
Dec
(1) |
2013 |
Jan
(6) |
Feb
(8) |
Mar
|
Apr
(10) |
May
(31) |
Jun
(7) |
Jul
(18) |
Aug
(33) |
Sep
(4) |
Oct
(16) |
Nov
|
Dec
(27) |
2014 |
Jan
(2) |
Feb
|
Mar
|
Apr
(11) |
May
(39) |
Jun
(8) |
Jul
(11) |
Aug
(4) |
Sep
|
Oct
(27) |
Nov
|
Dec
(71) |
2015 |
Jan
(17) |
Feb
(47) |
Mar
(33) |
Apr
|
May
|
Jun
(9) |
Jul
(7) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(8) |
2016 |
Jan
(4) |
Feb
(4) |
Mar
|
Apr
|
May
(12) |
Jun
(7) |
Jul
(9) |
Aug
(31) |
Sep
(8) |
Oct
(3) |
Nov
(15) |
Dec
(1) |
2017 |
Jan
(13) |
Feb
(7) |
Mar
(14) |
Apr
(8) |
May
(10) |
Jun
(4) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
(8) |
Nov
(4) |
Dec
(5) |
2018 |
Jan
(2) |
Feb
(8) |
Mar
|
Apr
(4) |
May
|
Jun
(6) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
2019 |
Jan
(1) |
Feb
(16) |
Mar
(1) |
Apr
(3) |
May
(5) |
Jun
(1) |
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
(1) |
Dec
(3) |
2020 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(2) |
Nov
|
Dec
(2) |
2021 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
(1) |
Nov
(1) |
Dec
(4) |
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(3) |
Sep
(2) |
Oct
(2) |
Nov
(4) |
Dec
|
2024 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(9) |
2025 |
Jan
|
Feb
(4) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: <sub...@co...> - 2011-08-30 15:04:23
|
Author: phd Date: Tue Aug 30 09:04:17 2011 New Revision: 4450 Log: Going to release SQLObject 1.1.3 and SQLObject 1.0.3. Modified: SQLObject/branches/1.1/docs/News.txt Modified: SQLObject/branches/1.1/docs/News.txt ============================================================================== --- SQLObject/branches/1.1/docs/News.txt Tue Aug 30 09:01:46 2011 (r4449) +++ SQLObject/branches/1.1/docs/News.txt Tue Aug 30 09:04:17 2011 (r4450) @@ -7,6 +7,13 @@ .. _start: +SQLObject 1.1.3 +=============== + +Released 30 Aug 2011. + +* A bugfix was ported from `SQLObject 1.0.3`_. + SQLObject 1.1.2 =============== @@ -55,6 +62,8 @@ SQLObject 1.0.3 =============== +Released 30 Aug 2011. + * Fixed a bug with Postgres - add quotes in "SET client_encoding" query. SQLObject 1.0.2 |
From: <sub...@co...> - 2011-08-30 15:01:53
|
Author: phd Date: Tue Aug 30 09:01:46 2011 New Revision: 4449 Log: Going to release SQLObject 1.0.3. Modified: SQLObject/branches/1.0/docs/News.txt Modified: SQLObject/branches/1.0/docs/News.txt ============================================================================== --- SQLObject/branches/1.0/docs/News.txt Wed Aug 24 11:37:02 2011 (r4448) +++ SQLObject/branches/1.0/docs/News.txt Tue Aug 30 09:01:46 2011 (r4449) @@ -10,10 +10,9 @@ SQLObject 1.0.3 =============== -* Fixed a bug with Postgres - add quotes in "SET client_encoding" query. +Released 30 Aug 2011. -SQLObject 1.0.2 -=============== +* Fixed a bug with Postgres - add quotes in "SET client_encoding" query. SQLObject 1.0.2 =============== |
From: <sub...@co...> - 2011-08-24 17:37:08
|
Author: phd Date: Wed Aug 24 11:37:02 2011 New Revision: 4448 Log: Merged revision 4447 from branch 1.1: fixed a bug with Postgres - add quotes in "SET client_encoding" query. Modified: SQLObject/trunk/docs/News.txt SQLObject/trunk/sqlobject/postgres/pgconnection.py Modified: SQLObject/trunk/docs/News.txt ============================================================================== --- SQLObject/trunk/docs/News.txt Wed Aug 24 11:35:44 2011 (r4447) +++ SQLObject/trunk/docs/News.txt Wed Aug 24 11:37:02 2011 (r4448) @@ -61,6 +61,11 @@ * All 'mydict.has_key(name)' checks were replaced with 'name in mydict'. +SQLObject 1.0.3 +=============== + +* Fixed a bug with Postgres - add quotes in "SET client_encoding" query. + SQLObject 1.0.2 =============== Modified: SQLObject/trunk/sqlobject/postgres/pgconnection.py ============================================================================== --- SQLObject/trunk/sqlobject/postgres/pgconnection.py Wed Aug 24 11:35:44 2011 (r4447) +++ SQLObject/trunk/sqlobject/postgres/pgconnection.py Wed Aug 24 11:37:02 2011 (r4448) @@ -137,7 +137,7 @@ c.execute("SET search_path TO " + self.schema) dbEncoding = self.dbEncoding if dbEncoding: - c.execute("SET client_encoding TO %s" % dbEncoding) + c.execute("SET client_encoding TO '%s'" % dbEncoding) return conn def _queryInsertID(self, conn, soInstance, id, names, values): |
From: <sub...@co...> - 2011-08-24 17:35:52
|
Author: phd Date: Wed Aug 24 11:35:44 2011 New Revision: 4447 Log: Merged revision 4446 from branch 1.0: fixed a bug with Postgres - add quotes in "SET client_encoding" query. Modified: SQLObject/branches/1.1/docs/News.txt SQLObject/branches/1.1/sqlobject/postgres/pgconnection.py Modified: SQLObject/branches/1.1/docs/News.txt ============================================================================== --- SQLObject/branches/1.1/docs/News.txt Wed Aug 24 11:32:50 2011 (r4446) +++ SQLObject/branches/1.1/docs/News.txt Wed Aug 24 11:35:44 2011 (r4447) @@ -52,6 +52,11 @@ * All 'mydict.has_key(name)' checks were replaced with 'name in mydict'. +SQLObject 1.0.3 +=============== + +* Fixed a bug with Postgres - add quotes in "SET client_encoding" query. + SQLObject 1.0.2 =============== Modified: SQLObject/branches/1.1/sqlobject/postgres/pgconnection.py ============================================================================== --- SQLObject/branches/1.1/sqlobject/postgres/pgconnection.py Wed Aug 24 11:32:50 2011 (r4446) +++ SQLObject/branches/1.1/sqlobject/postgres/pgconnection.py Wed Aug 24 11:35:44 2011 (r4447) @@ -137,7 +137,7 @@ c.execute("SET search_path TO " + self.schema) dbEncoding = self.dbEncoding if dbEncoding: - c.execute("SET client_encoding TO %s" % dbEncoding) + c.execute("SET client_encoding TO '%s'" % dbEncoding) return conn def _queryInsertID(self, conn, soInstance, id, names, values): |
From: <sub...@co...> - 2011-08-24 17:35:44
|
Author: phd Date: Wed Aug 24 11:32:50 2011 New Revision: 4446 Log: Fixed a bug with Postgres - add quotes in "SET client_encoding" query. Modified: SQLObject/branches/1.0/docs/News.txt SQLObject/branches/1.0/sqlobject/postgres/pgconnection.py Modified: SQLObject/branches/1.0/docs/News.txt ============================================================================== --- SQLObject/branches/1.0/docs/News.txt Sun Aug 21 13:32:38 2011 (r4445) +++ SQLObject/branches/1.0/docs/News.txt Wed Aug 24 11:32:50 2011 (r4446) @@ -7,6 +7,14 @@ .. _start: +SQLObject 1.0.3 +=============== + +* Fixed a bug with Postgres - add quotes in "SET client_encoding" query. + +SQLObject 1.0.2 +=============== + SQLObject 1.0.2 =============== Modified: SQLObject/branches/1.0/sqlobject/postgres/pgconnection.py ============================================================================== --- SQLObject/branches/1.0/sqlobject/postgres/pgconnection.py Sun Aug 21 13:32:38 2011 (r4445) +++ SQLObject/branches/1.0/sqlobject/postgres/pgconnection.py Wed Aug 24 11:32:50 2011 (r4446) @@ -137,7 +137,7 @@ c.execute("SET search_path TO " + self.schema) dbEncoding = self.dbEncoding if dbEncoding: - c.execute("SET client_encoding TO %s" % dbEncoding) + c.execute("SET client_encoding TO '%s'" % dbEncoding) return conn def _queryInsertID(self, conn, soInstance, id, names, values): |
From: <sub...@co...> - 2011-08-21 19:32:46
|
Author: phd Date: Sun Aug 21 13:32:38 2011 New Revision: 4445 Log: Convert documentation to Sphinx format and publish it on readthedocs.org. Modified: SQLObject/trunk/docs/TODO.txt Modified: SQLObject/trunk/docs/TODO.txt ============================================================================== --- SQLObject/trunk/docs/TODO.txt Mon Aug 8 06:52:30 2011 (r4444) +++ SQLObject/trunk/docs/TODO.txt Sun Aug 21 13:32:38 2011 (r4445) @@ -97,6 +97,11 @@ * Or move column values access to a separate namespace, e.g. .c: row.c.name. +* Convert documentation to Sphinx_ format and publish it on + http://readthedocs.org/ + +.. _Sphinx: http://sphinx.pocoo.org/index.html + * More documentation. Wiki. Trac. Mercurial. * RSS 2.0 and Atom news feeds. |
From: <sub...@co...> - 2011-08-08 12:52:37
|
Author: phd Date: Mon Aug 8 06:52:30 2011 New Revision: 4444 Log: Fixed import. Modified: SQLObject/tags/1.1.2/setup.py Modified: SQLObject/tags/1.1.2/setup.py ============================================================================== --- SQLObject/tags/1.1.2/setup.py Mon Aug 8 06:51:43 2011 (r4443) +++ SQLObject/tags/1.1.2/setup.py Mon Aug 8 06:52:30 2011 (r4444) @@ -9,7 +9,7 @@ from distutils.core import setup is_setuptools = False -from sqlobject import version +from sqlobject import version, version_info subpackages = ['firebird', 'include', 'include.pydispatch', 'inheritance', 'manager', 'maxdb', 'mysql', 'mssql', 'postgres', 'rdbhost', |
From: <sub...@co...> - 2011-08-08 12:51:49
|
Author: phd Date: Mon Aug 8 06:51:43 2011 New Revision: 4443 Log: Fixed import. Modified: SQLObject/branches/1.1/setup.py Modified: SQLObject/branches/1.1/setup.py ============================================================================== --- SQLObject/branches/1.1/setup.py Mon Aug 8 06:50:07 2011 (r4442) +++ SQLObject/branches/1.1/setup.py Mon Aug 8 06:51:43 2011 (r4443) @@ -9,7 +9,7 @@ from distutils.core import setup is_setuptools = False -from sqlobject import version +from sqlobject import version, version_info subpackages = ['firebird', 'include', 'include.pydispatch', 'inheritance', 'manager', 'maxdb', 'mysql', 'mssql', 'postgres', 'rdbhost', |
From: <sub...@co...> - 2011-08-08 12:50:17
|
Author: phd Date: Mon Aug 8 06:50:07 2011 New Revision: 4442 Log: Releasing stable version 1.1.2. Modified: SQLObject/tags/1.1.2/README.txt SQLObject/tags/1.1.2/setup.cfg SQLObject/tags/1.1.2/setup.py SQLObject/tags/1.1.2/sqlobject/__init__.py SQLObject/tags/1.1.2/sqlobject/__version__.py SQLObject/tags/1.1.2/sqlobject/main.py Modified: SQLObject/tags/1.1.2/README.txt ============================================================================== --- SQLObject/tags/1.1.2/README.txt Mon Aug 8 06:49:15 2011 (r4441) +++ SQLObject/tags/1.1.2/README.txt Mon Aug 8 06:50:07 2011 (r4442) @@ -1,5 +1,5 @@ -SQLObject 1.1 -============= +SQLObject 1.1.2 +=============== Thanks for looking at SQLObject. SQLObject is an object-relational mapper, i.e., a library that will wrap your database tables in Python Modified: SQLObject/tags/1.1.2/setup.cfg ============================================================================== --- SQLObject/tags/1.1.2/setup.cfg Mon Aug 8 06:49:15 2011 (r4441) +++ SQLObject/tags/1.1.2/setup.cfg Mon Aug 8 06:50:07 2011 (r4442) @@ -5,10 +5,6 @@ [easy_install] #find_links = http://svn.pythonpaste.org/package_index.html -[egg_info] -tag_build = dev -tag_svn_revision = true - [pudge] theme = pythonpaste.org docs = docs/index.txt docs/Authors.txt docs/DeveloperGuide.txt docs/FAQ.txt Modified: SQLObject/tags/1.1.2/setup.py ============================================================================== --- SQLObject/tags/1.1.2/setup.py Mon Aug 8 06:49:15 2011 (r4441) +++ SQLObject/tags/1.1.2/setup.py Mon Aug 8 06:50:07 2011 (r4442) @@ -37,8 +37,8 @@ Supports MySQL, PostgreSQL, SQLite, Firebird, Sybase, MSSQL and MaxDB (SAPDB). For development see the `subversion repository -<http://svn.colorstudy.com/SQLObject/trunk>`_ -""", +<http://svn.colorstudy.com/SQLObject/branches/%s/>`_ +""" % '.'.join([str(v) for v in version_info[:2]]), classifiers=[ "Development Status :: 5 - Production/Stable", "Intended Audience :: Developers", Modified: SQLObject/tags/1.1.2/sqlobject/__init__.py ============================================================================== --- SQLObject/tags/1.1.2/sqlobject/__init__.py Mon Aug 8 06:49:15 2011 (r4441) +++ SQLObject/tags/1.1.2/sqlobject/__init__.py Mon Aug 8 06:50:07 2011 (r4442) @@ -1,5 +1,5 @@ """ -SQLObject 1.1 +SQLObject 1.1.2 """ from __version__ import version, version_info Modified: SQLObject/tags/1.1.2/sqlobject/__version__.py ============================================================================== --- SQLObject/tags/1.1.2/sqlobject/__version__.py Mon Aug 8 06:49:15 2011 (r4441) +++ SQLObject/tags/1.1.2/sqlobject/__version__.py Mon Aug 8 06:50:07 2011 (r4442) @@ -1,8 +1,8 @@ -version = '1.1' +version = '1.1.2' major = 1 minor = 1 -micro = 0 -release_level = 'branch' +micro = 2 +release_level = 'final' serial = 0 version_info = (major, minor, micro, release_level, serial) Modified: SQLObject/tags/1.1.2/sqlobject/main.py ============================================================================== --- SQLObject/tags/1.1.2/sqlobject/main.py Mon Aug 8 06:49:15 2011 (r4441) +++ SQLObject/tags/1.1.2/sqlobject/main.py Mon Aug 8 06:50:07 2011 (r4442) @@ -1,6 +1,6 @@ """ -SQLObject 1.1 -------------- +SQLObject 1.1.2 +--------------- :author: Ian Bicking <ia...@co...> |
From: <sub...@co...> - 2011-08-08 12:49:21
|
Author: phd Date: Mon Aug 8 06:49:15 2011 New Revision: 4441 Log: Development URL is a branch, not the trunk. Modified: SQLObject/branches/1.1/setup.py Modified: SQLObject/branches/1.1/setup.py ============================================================================== --- SQLObject/branches/1.1/setup.py Mon Aug 8 06:45:53 2011 (r4440) +++ SQLObject/branches/1.1/setup.py Mon Aug 8 06:49:15 2011 (r4441) @@ -37,8 +37,8 @@ Supports MySQL, PostgreSQL, SQLite, Firebird, Sybase, MSSQL and MaxDB (SAPDB). For development see the `subversion repository -<http://svn.colorstudy.com/SQLObject/trunk>`_ -""", +<http://svn.colorstudy.com/SQLObject/branches/%s/>`_ +""" % '.'.join([str(v) for v in version_info[:2]]), classifiers=[ "Development Status :: 5 - Production/Stable", "Intended Audience :: Developers", |
From: <sub...@co...> - 2011-08-08 12:46:00
|
Author: phd Date: Mon Aug 8 06:45:53 2011 New Revision: 4440 Log: Tagging 1.1.2 Added: SQLObject/tags/1.1.2/ - copied from r4439, SQLObject/branches/1.1/ |
From: <sub...@co...> - 2011-08-08 12:40:59
|
Author: phd Date: Mon Aug 8 06:40:52 2011 New Revision: 4439 Log: Releasing stable version 1.0.2. Modified: SQLObject/tags/1.0.2/README.txt SQLObject/tags/1.0.2/setup.cfg SQLObject/tags/1.0.2/sqlobject/__init__.py SQLObject/tags/1.0.2/sqlobject/__version__.py SQLObject/tags/1.0.2/sqlobject/main.py Modified: SQLObject/tags/1.0.2/README.txt ============================================================================== --- SQLObject/tags/1.0.2/README.txt Mon Aug 8 06:32:32 2011 (r4438) +++ SQLObject/tags/1.0.2/README.txt Mon Aug 8 06:40:52 2011 (r4439) @@ -1,5 +1,5 @@ -SQLObject 1.0 -============= +SQLObject 1.0.2 +=============== Thanks for looking at SQLObject. SQLObject is an object-relational mapper, i.e., a library that will wrap your database tables in Python Modified: SQLObject/tags/1.0.2/setup.cfg ============================================================================== --- SQLObject/tags/1.0.2/setup.cfg Mon Aug 8 06:32:32 2011 (r4438) +++ SQLObject/tags/1.0.2/setup.cfg Mon Aug 8 06:40:52 2011 (r4439) @@ -5,10 +5,6 @@ [easy_install] #find_links = http://svn.pythonpaste.org/package_index.html -[egg_info] -tag_build = dev -tag_svn_revision = true - [pudge] theme = pythonpaste.org docs = docs/index.txt docs/Authors.txt docs/DeveloperGuide.txt docs/FAQ.txt Modified: SQLObject/tags/1.0.2/sqlobject/__init__.py ============================================================================== --- SQLObject/tags/1.0.2/sqlobject/__init__.py Mon Aug 8 06:32:32 2011 (r4438) +++ SQLObject/tags/1.0.2/sqlobject/__init__.py Mon Aug 8 06:40:52 2011 (r4439) @@ -1,5 +1,5 @@ """ -SQLObject 1.0 +SQLObject 1.0.2 """ from __version__ import version, version_info Modified: SQLObject/tags/1.0.2/sqlobject/__version__.py ============================================================================== --- SQLObject/tags/1.0.2/sqlobject/__version__.py Mon Aug 8 06:32:32 2011 (r4438) +++ SQLObject/tags/1.0.2/sqlobject/__version__.py Mon Aug 8 06:40:52 2011 (r4439) @@ -1,8 +1,8 @@ -version = '1.0' +version = '1.0.2' major = 1 minor = 0 -micro = 0 -release_level = 'branch' +micro = 2 +release_level = 'final' serial = 0 version_info = (major, minor, micro, release_level, serial) Modified: SQLObject/tags/1.0.2/sqlobject/main.py ============================================================================== --- SQLObject/tags/1.0.2/sqlobject/main.py Mon Aug 8 06:32:32 2011 (r4438) +++ SQLObject/tags/1.0.2/sqlobject/main.py Mon Aug 8 06:40:52 2011 (r4439) @@ -1,6 +1,6 @@ """ -SQLObject 1.0 -------------- +SQLObject 1.0.2 +--------------- :author: Ian Bicking <ia...@co...> |
From: <sub...@co...> - 2011-08-08 12:32:38
|
Author: phd Date: Mon Aug 8 06:32:32 2011 New Revision: 4438 Log: Tagging 1.0.2 Added: SQLObject/tags/1.0.2/ - copied from r4437, SQLObject/branches/1.0/ |
From: <sub...@co...> - 2011-08-08 12:32:01
|
Author: phd Date: Mon Aug 8 06:31:54 2011 New Revision: 4437 Log: Going to release SQLObject 1.0.2 and SQLObject 1.1.2. Modified: SQLObject/trunk/docs/News.txt Modified: SQLObject/trunk/docs/News.txt ============================================================================== --- SQLObject/trunk/docs/News.txt Mon Aug 8 06:31:07 2011 (r4436) +++ SQLObject/trunk/docs/News.txt Mon Aug 8 06:31:54 2011 (r4437) @@ -19,6 +19,8 @@ SQLObject 1.1.2 =============== +Released 8 Aug 2011. + * A bugfix was ported from `SQLObject 1.0.2`_. SQLObject 1.1.1 @@ -62,6 +64,8 @@ SQLObject 1.0.2 =============== +Released 8 Aug 2011. + * A bug was fixed in SelectResults slicing that prevented to slice a slice (my_results[:20][1:5]). |
From: <sub...@co...> - 2011-08-08 12:31:13
|
Author: phd Date: Mon Aug 8 06:31:07 2011 New Revision: 4436 Log: Going to release SQLObject 1.0.2 and SQLObject 1.1.2. Modified: SQLObject/branches/1.1/docs/News.txt Modified: SQLObject/branches/1.1/docs/News.txt ============================================================================== --- SQLObject/branches/1.1/docs/News.txt Mon Aug 8 06:29:52 2011 (r4435) +++ SQLObject/branches/1.1/docs/News.txt Mon Aug 8 06:31:07 2011 (r4436) @@ -10,6 +10,8 @@ SQLObject 1.1.2 =============== +Released 8 Aug 2011. + * A bugfix was ported from `SQLObject 1.0.2`_. SQLObject 1.1.1 @@ -53,6 +55,8 @@ SQLObject 1.0.2 =============== +Released 8 Aug 2011. + * A bug was fixed in SelectResults slicing that prevented to slice a slice (my_results[:20][1:5]). |
From: <sub...@co...> - 2011-08-08 12:30:02
|
Author: phd Date: Mon Aug 8 06:29:52 2011 New Revision: 4435 Log: Going to release SQLObject 1.0.2. Modified: SQLObject/branches/1.0/docs/News.txt Modified: SQLObject/branches/1.0/docs/News.txt ============================================================================== --- SQLObject/branches/1.0/docs/News.txt Thu Aug 4 08:00:11 2011 (r4434) +++ SQLObject/branches/1.0/docs/News.txt Mon Aug 8 06:29:52 2011 (r4435) @@ -10,6 +10,8 @@ SQLObject 1.0.2 =============== +Released 8 Aug 2011. + * A bug was fixed in SelectResults slicing that prevented to slice a slice (my_results[:20][1:5]). |
From: SourceForge.net <no...@so...> - 2011-08-04 14:03:14
|
Bugs item #3293195, was opened at 2011-04-26 20:32 Message generated for change (Settings changed) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540672&aid=3293195&group_id=74338 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General >Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: https://www.google.com/accounts () >Assigned to: Oleg Broytman (phd) Summary: problem installing SQLObject 1.0.0. using pip Initial Comment: Hello guys, there seem to be a bug while installing the SQLObject using pip. See below: [os-py27] os@[dyn3 ~]> pip install -r os/requirements.txt Downloading/unpacking FormEncode>=1.2.4 (from -r os/requirements.txt (line 1)) Running setup.py egg_info for package FormEncode warning: no files found matching '*.py' under directory '.' no previously-included directories found matching '**/.svn' Downloading/unpacking Django>=1.3 (from -r os/requirements.txt (line 2)) Running setup.py egg_info for package Django Downloading/unpacking psycopg2>=2.4 (from -r os/requirements.txt (line 3)) Running setup.py egg_info for package psycopg2 no previously-included directories found matching 'doc/src/_build' Downloading/unpacking IMDbPY>=4.7 (from -r os/requirements.txt (line 4)) Running setup.py egg_info for package IMDbPY Created locale for: en tr it. warning: no previously-included files matching '*~' found anywhere in distribution no previously-included directories found matching 'CVS' no previously-included directories found matching '.svn' no previously-included directories found matching '.hg' warning: no previously-included files matching 'CVS' found anywhere in distribution warning: no previously-included files matching '.svn' found anywhere in distribution Downloading/unpacking chardet>=1.0.1 (from -r opensubtitles/requirements.txt (line 5)) Running setup.py egg_info for package chardet Obtaining pysublib from hg+http://bitbucket.org/danger/pysublib/#egg=pysublib (from -r os/requirements.txt (line 6)) Updating ./.virtualenvs/os-py27/src/pysublib clone warning: bitbucket.org certificate with fingerprint 81:2b:08:90:dc:d3:71:ee:e0:7c:b4:75:ce:9b:6c:48:94:56:a1:fe not verified (check hostfingerprints or web.cacerts config setting) Running setup.py egg_info for package pysublib Downloading/unpacking SQLObject (from IMDbPY>=4.7->-r os/requirements.txt (line 4)) Running setup.py egg_info for package SQLObject Traceback (most recent call last): File "<string>", line 14, in <module> File "/data/www/ng.os.org/.virtualenvs/os-py27/build/SQLObject/setup.py", line 12, in <module> from sqlobject import version, version_info File "sqlobject/__init__.py", line 6, in <module> from col import * File "sqlobject/col.py", line 31, in <module> from formencode import compound ImportError: No module named formencode Complete output from command python setup.py egg_info: Traceback (most recent call last): File "<string>", line 14, in <module> File "/data/www/ng.os.org/.virtualenvs/os-py27/build/SQLObject/setup.py", line 12, in <module> from sqlobject import version, version_info File "sqlobject/__init__.py", line 6, in <module> from col import * File "sqlobject/col.py", line 31, in <module> from formencode import compound ImportError: No module named formencode ---------------------------------------- Command python setup.py egg_info failed with error code 1 Storing complete log in /data/www/ng.os.org/.pip/pip.log Exit 1 [os-py27] os@[dyn3 ~]> cat os/requirements.txt FormEncode>=1.2.4 Django>=1.3 psycopg2>=2.4 IMDbPY>=4.7 chardet>=1.0.1 -e hg+http://bitbucket.org/danger/pysublib/#egg=pysublib Here is also a snipped of my discussion on #pip on IRC: 18:23:31 < agronholm> no, but this is an sqlobject bug 18:23:38 < agronholm> it's importing stuff it shouldn't in setup.py 18:23:41 < carljm> DanGer: The only fix that will make this work for automated deployment is to fix SQLObject's setup.py. 18:23:43 < agronholm> not much we can do about it 18:24:06 < DanGer> agronholm: I tried listing formencode before imdbpy in requirements, but it seems not to install things in the order listed in requirements.txt 18:24:15 < carljm> DanGer: order is irrelevant. 18:24:34 < carljm> Pip needs to get metadata from all packages in the to-be-installed set before it installs any of them, that's a core design goal of pip. 18:24:47 < carljm> This is failing at the get-metadata step, because of the broken setup.py. 18:25:20 < carljm> So regardless of order, nothing in your requirements.txt will be installed yet at this stage. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540672&aid=3293195&group_id=74338 |
From: SourceForge.net <no...@so...> - 2011-08-04 14:02:10
|
Patches item #3385538, was opened at 2011-08-03 15:35 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=3385538&group_id=74338 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: RuneH (runefh) >Assigned to: Oleg Broytman (phd) Summary: Fix for 3293195 Initial Comment: 3293195 fails because setup.py tries to import sqlobject before its dependencies are met. The patch stops setup.py from importing sqlobject, instead imports only the __version__ module via imp.load_source. ---------------------------------------------------------------------- >Comment By: Oleg Broytman (phd) Date: 2011-08-04 18:02 Message: Applied and committed in the revision 4434 in the trunk. Will be in the next release (1.2). Thank you! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=3385538&group_id=74338 |
From: <sub...@co...> - 2011-08-04 14:00:19
|
Author: phd Date: Thu Aug 4 08:00:11 2011 New Revision: 4434 Log: Do not import sqlobject before dependencies are met; instead imports only the __version__ module via imp.load_source. Modified: SQLObject/trunk/setup.py Modified: SQLObject/trunk/setup.py ============================================================================== --- SQLObject/trunk/setup.py Wed Jul 27 03:47:55 2011 (r4433) +++ SQLObject/trunk/setup.py Thu Aug 4 08:00:11 2011 (r4434) @@ -1,5 +1,8 @@ #!/usr/bin/env python +from imp import load_source +from os.path import abspath, dirname, isfile, join + try: from ez_setup import use_setuptools use_setuptools() @@ -9,7 +12,9 @@ from distutils.core import setup is_setuptools = False -from sqlobject import version +versionpath = join(abspath(dirname(__file__)), "sqlobject", "__version__.py") +load_source("sqlobject_version", versionpath) +from sqlobject_version import version subpackages = ['firebird', 'include', 'include.pydispatch', 'inheritance', 'manager', 'maxdb', 'mysql', 'mssql', 'postgres', 'rdbhost', |
From: SourceForge.net <no...@so...> - 2011-08-03 11:35:16
|
Patches item #3385538, was opened at 2011-08-03 13:35 Message generated for change (Tracker Item Submitted) made by runefh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=3385538&group_id=74338 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: RuneH (runefh) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for 3293195 Initial Comment: 3293195 fails because setup.py tries to import sqlobject before its dependencies are met. The patch stops setup.py from importing sqlobject, instead imports only the __version__ module via imp.load_source. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=3385538&group_id=74338 |
From: <sub...@co...> - 2011-07-27 09:48:02
|
Author: phd Date: Wed Jul 27 03:47:55 2011 New Revision: 4433 Log: Updated docs. Modified: SQLObject/trunk/docs/News.txt SQLObject/trunk/docs/TODO.txt Modified: SQLObject/trunk/docs/News.txt ============================================================================== --- SQLObject/trunk/docs/News.txt Wed Jul 27 03:45:40 2011 (r4432) +++ SQLObject/trunk/docs/News.txt Wed Jul 27 03:47:55 2011 (r4433) @@ -16,6 +16,11 @@ * A bug caused by psycopg2 recently added a new boolean not callable autocommit attribute was fixed. +SQLObject 1.1.2 +=============== + +* A bugfix was ported from `SQLObject 1.0.2`_. + SQLObject 1.1.1 =============== Modified: SQLObject/trunk/docs/TODO.txt ============================================================================== --- SQLObject/trunk/docs/TODO.txt Wed Jul 27 03:45:40 2011 (r4432) +++ SQLObject/trunk/docs/TODO.txt Wed Jul 27 03:47:55 2011 (r4433) @@ -1,6 +1,8 @@ TODO ---- +* Make strings special-cased in Select to allow Select(['name', 'value']). + * Allow to override ConsoleWriter/LogWriter classes and makeDebugWriter function. @@ -35,6 +37,8 @@ * TimedeltaCol +* Cached join results. + * Invert tests isinstance(obj, (tuple, list)) to not isinstance(obj, basestr) to allow any iterable. |
From: <sub...@co...> - 2011-07-27 09:45:49
|
Author: phd Date: Wed Jul 27 03:45:40 2011 New Revision: 4432 Log: SQLObject 1.1.2: A bugfix was ported from SQLObject 1.0.2. Modified: SQLObject/branches/1.1/docs/News.txt Modified: SQLObject/branches/1.1/docs/News.txt ============================================================================== --- SQLObject/branches/1.1/docs/News.txt Mon Jul 18 14:37:08 2011 (r4431) +++ SQLObject/branches/1.1/docs/News.txt Wed Jul 27 03:45:40 2011 (r4432) @@ -7,6 +7,11 @@ .. _start: +SQLObject 1.1.2 +=============== + +* A bugfix was ported from `SQLObject 1.0.2`_. + SQLObject 1.1.1 =============== |
From: SourceForge.net <no...@so...> - 2011-07-20 13:33:18
|
Support Requests item #3366899, was opened at 2011-07-14 11:40 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540673&aid=3366899&group_id=74338 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Priority: 5 Private: No Submitted By: Rosa Robles (marobles) Assigned to: Oleg Broytman (phd) Summary: The speed of SQLObject is slower on the time Initial Comment: I had a test of a SQLObject and I had found a strange behaviour of SQLObject. On the time, the respond time is lesser. Here, I put a example of test code : from sqlobject.sqlbuilder import * connection = connectionForURI('postgresql://test:test@localhost/test_sql_object') sqlhub.processConnection = connection class Person(SQLObject): firstName = StringCol() middleInitial = StringCol(length=1, default=None) lastName = StringCol() iteration = 0 while 1: start = datetime.now() person_list = [] for key in range(1000): person = Person.selectBy(firstName='name%s%s' % (iteration,key))[0] person_list.append(person) for person in person_list: person.expire() del person del person_list sqlhub.processConnection.cache.clear() end = datetime.now() print "TIME ",iteration,':' , end - start iteration = iteration + 1 In the result I can check that in each iteration the time is bigger. The first iteration has time of 1.37s, then the time increases and the 19 iteration has time of 5.83 s! TIME 0 : 0:00:01.376392 TIME 1 : 0:00:01.663250 TIME 2 : 0:00:01.978639 TIME 3 : 0:00:02.319939 TIME 4 : 0:00:02.618213 TIME 5 : 0:00:02.723846 TIME 6 : 0:00:02.584007 TIME 7 : 0:00:02.868877 TIME 8 : 0:00:03.051937 TIME 9 : 0:00:03.389757 TIME 10 : 0:00:03.503036 TIME 11 : 0:00:03.563154 TIME 12 : 0:00:04.191539 TIME 13 : 0:00:04.274464 TIME 14 : 0:00:04.813206 TIME 15 : 0:00:04.677002 TIME 16 : 0:00:04.995708 TIME 17 : 0:00:05.126811 TIME 18 : 0:00:05.571279 TIME 19 : 0:00:05.832840 Why is happend this? Thanks in advance for your attention. Cheers Rosa ---------------------------------------------------------------------- >Comment By: Oleg Broytman (phd) Date: 2011-07-20 17:33 Message: MySQL is different, AFAIU, because it has only client-side cursors instead of server-side; i.e. MySQLdb fetches all results even if SQLObject asks to fetch one row. ---------------------------------------------------------------------- Comment By: Rosa Robles (marobles) Date: 2011-07-20 10:32 Message: I didn't know profiler tool, thanks very much, Oleg!! I'm agree with you source of problem, in postgres it spends almost all time in method 'execute' of 'psycopg2._psycopg.cursor' objects however in mysql it spends almost all time in method 'query' of '_mysql.connection' objects. The problem is in the use of database, a lots of operations to database spends a lots time. Thanks very much, your help has been very useful to me. ---------------------------------------------------------------------- Comment By: Oleg Broytman (phd) Date: 2011-07-19 21:09 Message: Well, I ran it myself: python -m cProfile -s cumulative test_sql_object_by_object.py. The results is 5089432 function calls (4987267 primitive calls) in 82.498 CPU seconds Ordered by: cumulative time ncalls tottime percall cumtime percall filename:lineno(function) 1 0.001 0.001 82.498 82.498 {execfile} 1 0.001 0.001 82.497 82.497 test_sql_object_by_object.py:3(<module>) 1 0.324 0.324 82.115 82.115 test_sql_object_by_object.py:50(select_examples) 20000 0.295 0.000 77.778 0.004 sresults.py:126(__getitem__) 20000 0.442 0.000 75.925 0.004 sresults.py:175(__iter__) 20000 0.107 0.000 69.318 0.003 sresults.py:181(lazyIter) 20000 0.150 0.000 69.076 0.003 dbconnection.py:470(iterSelect) 20000 0.202 0.000 68.665 0.003 dbconnection.py:705(__init__) 20001 0.085 0.000 60.550 0.003 sqliteconnection.py:194(_executeRetry) 20001 60.465 0.003 60.465 0.003 {method 'execute' of 'pysqlite2.dbapi2.Cursor' objects} 20000 0.156 0.000 7.846 0.000 dbconnection.py:485(queryForSelect) 40000 0.332 0.000 5.945 0.000 dbconnection.py:719(next) 40000 0.170 0.000 5.601 0.000 dbconnection.py:670(sqlrepr) 140000/40000 0.584 0.000 5.430 0.000 converters.py:198(sqlrepr) 20000 1.305 0.000 4.802 0.000 sqlbuilder.py:613(__sqlrepr__) 20000 0.399 0.000 4.536 0.000 main.py:878(get) 20000 0.205 0.000 3.503 0.000 main.py:1373(selectBy) 20000 0.182 0.000 2.920 0.000 main.py:915(_init) 20000 0.655 0.000 2.735 0.000 sresults.py:42(queryForSelect) 140000 0.679 0.000 2.704 0.000 sqlbuilder.py:215(tablesUsedSet) 40000 0.931 0.000 2.620 0.000 sresults.py:9(__init__) 20000 0.440 0.000 2.373 0.000 main.py:1154(_SO_selectInit) 220568 0.660 0.000 1.967 0.000 {getattr} 80000 0.776 0.000 1.950 0.000 col.py:503(to_python) 140000 1.078 0.000 1.793 0.000 sqlbuilder.py:194(tablesUsedSet) 20000 0.465 0.000 1.699 0.000 dbconnection.py:641(_SO_columnClause) 20000 0.183 0.000 1.492 0.000 sresults.py:89(clone) 80000 0.446 0.000 1.431 0.000 sqlbuilder.py:391(__getattr__) 100024 0.597 0.000 1.173 0.000 dbconnection.py:896(__get__) 564108 1.073 0.000 1.073 0.000 {isinstance} The entire program took 80 seconds, of which 60 seconds were spend in method 'execute' of 'pysqlite2.dbapi2.Cursor' (I used sqlite). Not an SQLObject fault. You can run a profiler yourself sorting by different column. I'd like to hear your interpretation. ---------------------------------------------------------------------- Comment By: Oleg Broytman (phd) Date: 2011-07-19 19:21 Message: To stop cache culling I added connection.cache = CacheSet(cullFrequency=10**6) to your test program. It didn't help. So it seems cache culling is not the culprit. There is a need to do a deeper investigation. Can you run a python profiler over your test(s)? ---------------------------------------------------------------------- Comment By: Rosa Robles (marobles) Date: 2011-07-19 12:09 Message: if we review the results, after read a lots of records selectBy takes more times, in the first iteration is almost zero but in 20 iteration is bigger. If you do the example, and you takes the times without to call to expireAll() or clear(), you can check that the time c for iteration in range(20): start = datetime.now() for key in range(1000): person = Person.selectBy(firstName='name%s%s' % (iteration,key))[0] end = datetime.now() print "ITERATION ",iteration, "TIME", end-start Person.sqlmeta.expireAll() sqlhub.getConnection().expireAll() connection.cache.clear() ---------------------------------------------------------------------- Comment By: Oleg Broytman (phd) Date: 2011-07-18 21:50 Message: time_end-time_start are consistently almost zero, so selectBy doesn't take time, right? ---------------------------------------------------------------------- Comment By: Rosa Robles (marobles) Date: 2011-07-18 10:36 Message: The program takes time only from the selectby operation for key in range(1000): time_start = datetime.now() person = Person.selectBy(firstName='name%s%s' %(iteration,key))[0] time_end = datetime.now() times.append(time_end-time_start) I attach the example to you can read better If we review the results, the selectBy method takes times random in iteration, but also each iteration's time grows up. I think the problem is in the execution of cull process when delete expiredCache values, what do you think? In my real program do not use select in mass but it can acumulate a lots operations of select in the time, then we have problems of memory and we must restart the application. May be this situation is the source of our problem with the memory. ---------------------------------------------------------------------- Comment By: Oleg Broytman (phd) Date: 2011-07-15 21:14 Message: Min/max/avg times are almost zero, so it seems the only place the program spends time is calling .expireAll() and cache.clear(), right? ---------------------------------------------------------------------- Comment By: Rosa Robles (marobles) Date: 2011-07-15 10:52 Message: Thanks Oleg. I'm using SQLObject 1.1.1, Python2.6, Postgres 8.4 Ok, I change the code to takes more times. for iteration in range(20): start = datetime.now() acum = timedelta(microseconds=0) times = [] for key in range(1000): time_start = datetime.now() person = Person.selectBy(firstName='name%s%s' % (iteration,key))[0] time_end = datetime.now() times.append(time_end-time_start) acum = acum + (time_end-time_start) end = datetime.now() print "ITERATION ",iteration,"time",end-start print " First Key ->", times[0] print " Last Key ->",times[999] print " Key ->",times.index(max(times)), " Max Time ->", max(times) print " Key ->",times.index(min(times)), " Min Time ->", min(times) print " avg ->",acum/999 Person.sqlmeta.expireAll() for k in connection.cache.caches.keys(): connection.cache.caches[k].expireAll() sqlhub.getConnection().expireAll() connection.cache.clear() gc.collect() And the result is: ITERATION 0 time 0:00:01.302290 First Key -> 0:00:00.001555 Last Key -> 0:00:00.001445 Key -> 11 Max Time -> 0:00:00.003216 Key -> 36 Min Time -> 0:00:00.001115 avg -> 0:00:00.001287 ITERATION 1 time 0:00:01.621580 First Key -> 0:00:00.001879 Last Key -> 0:00:00.001734 Key -> 924 Max Time -> 0:00:00.009572 Key -> 22 Min Time -> 0:00:00.001076 avg -> 0:00:00.001606 ITERATION 2 time 0:00:01.851719 First Key -> 0:00:00.002328 Last Key -> 0:00:00.002064 Key -> 970 Max Time -> 0:00:00.002544 Key -> 22 Min Time -> 0:00:00.001306 avg -> 0:00:00.001836 ITERATION 3 time 0:00:02.040802 First Key -> 0:00:00.002435 Last Key -> 0:00:00.002376 Key -> 557 Max Time -> 0:00:00.009674 Key -> 25 Min Time -> 0:00:00.001538 avg -> 0:00:00.002026 ITERATION 4 time 0:00:02.427911 First Key -> 0:00:00.002906 Last Key -> 0:00:00.002065 Key -> 774 Max Time -> 0:00:00.003263 Key -> 7 Min Time -> 0:00:00.001763 avg -> 0:00:00.002413 ITERATION 5 time 0:00:02.768819 First Key -> 0:00:00.003051 Last Key -> 0:00:00.002319 Key -> 920 Max Time -> 0:00:00.007694 Key -> 11 Min Time -> 0:00:00.002007 avg -> 0:00:00.002753 ITERATION 6 time 0:00:02.537283 First Key -> 0:00:00.002676 Last Key -> 0:00:00.002549 Key -> 2 Max Time -> 0:00:00.003512 Key -> 132 Min Time -> 0:00:00.002318 avg -> 0:00:00.002523 ITERATION 7 time 0:00:02.723405 First Key -> 0:00:00.005272 Last Key -> 0:00:00.002788 Key -> 79 Max Time -> 0:00:00.007543 Key -> 12 Min Time -> 0:00:00.002457 avg -> 0:00:00.002709 ITERATION 8 time 0:00:02.947676 First Key -> 0:00:00.003161 Last Key -> 0:00:00.003028 Key -> 1 Max Time -> 0:00:00.006068 Key -> 31 Min Time -> 0:00:00.002683 avg -> 0:00:00.002933 ITERATION 9 time 0:00:03.781268 First Key -> 0:00:00.004271 Last Key -> 0:00:00.003416 Key -> 930 Max Time -> 0:00:00.011791 Key -> 5 Min Time -> 0:00:00.003029 avg -> 0:00:00.003765 ITERATION 10 time 0:00:03.842353 First Key -> 0:00:00.006544 Last Key -> 0:00:00.003394 Key -> 0 Max Time -> 0:00:00.006544 Key -> 4 Min Time -> 0:00:00.003171 avg -> 0:00:00.003826 ITERATION 11 time 0:00:03.361368 First Key -> 0:00:00.001509 Last Key -> 0:00:00.003626 Key -> 602 Max Time -> 0:00:00.009093 Key -> 9 Min Time -> 0:00:00.001089 avg -> 0:00:00.003346 ITERATION 12 time 0:00:03.581802 First Key -> 0:00:00.001511 Last Key -> 0:00:00.003912 Key -> 474 Max Time -> 0:00:00.009027 Key -> 1 Min Time -> 0:00:00.001117 avg -> 0:00:00.003566 ITERATION 13 time 0:00:03.797965 First Key -> 0:00:00.001833 Last Key -> 0:00:00.004118 Key -> 100 Max Time -> 0:00:00.005115 Key -> 9 Min Time -> 0:00:00.001126 avg -> 0:00:00.003782 ITERATION 14 time 0:00:04.147961 First Key -> 0:00:00.001851 Last Key -> 0:00:00.004362 Key -> 782 Max Time -> 0:00:00.013857 Key -> 16 Min Time -> 0:00:00.001186 avg -> 0:00:00.004132 ITERATION 15 time 0:00:04.251830 First Key -> 0:00:00.001538 Last Key -> 0:00:00.004611 Key -> 518 Max Time -> 0:00:00.009511 Key -> 9 Min Time -> 0:00:00.001114 avg -> 0:00:00.004236 ITERATION 16 time 0:00:04.487687 First Key -> 0:00:00.001541 Last Key -> 0:00:00.004994 Key -> 858 Max Time -> 0:00:00.009368 Key -> 9 Min Time -> 0:00:00.001120 avg -> 0:00:00.004472 ITERATION 17 time 0:00:04.703588 First Key -> 0:00:00.003440 Last Key -> 0:00:00.005104 Key -> 529 Max Time -> 0:00:00.008179 Key -> 8 Min Time -> 0:00:00.001105 avg -> 0:00:00.004688 ITERATION 18 time 0:00:05.300920 First Key -> 0:00:00.001851 Last Key -> 0:00:00.006987 Key -> 854 Max Time -> 0:00:00.007299 Key -> 9 Min Time -> 0:00:00.001181 avg -> 0:00:00.005285 ITERATION 19 time 0:00:06.168681 First Key -> 0:00:00.001880 Last Key -> 0:00:00.005577 Key -> 911 Max Time -> 0:00:00.009503 Key -> 9 Min Time -> 0:00:00.001119 avg -> 0:00:00.006152 ---------------------------------------------------------------------- Comment By: Oleg Broytman (phd) Date: 2011-07-14 20:56 Message: No idea what is going on. Let's investigate a little further. What version of SQLObject are you using? Can you add more prints inside the loop to see what part of the program takes time? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540673&aid=3366899&group_id=74338 |
From: SourceForge.net <no...@so...> - 2011-07-20 06:32:57
|
Support Requests item #3366899, was opened at 2011-07-14 09:40 Message generated for change (Comment added) made by marobles You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540673&aid=3366899&group_id=74338 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Private: No Submitted By: Rosa Robles (marobles) Assigned to: Oleg Broytman (phd) Summary: The speed of SQLObject is slower on the time Initial Comment: I had a test of a SQLObject and I had found a strange behaviour of SQLObject. On the time, the respond time is lesser. Here, I put a example of test code : from sqlobject.sqlbuilder import * connection = connectionForURI('postgresql://test:test@localhost/test_sql_object') sqlhub.processConnection = connection class Person(SQLObject): firstName = StringCol() middleInitial = StringCol(length=1, default=None) lastName = StringCol() iteration = 0 while 1: start = datetime.now() person_list = [] for key in range(1000): person = Person.selectBy(firstName='name%s%s' % (iteration,key))[0] person_list.append(person) for person in person_list: person.expire() del person del person_list sqlhub.processConnection.cache.clear() end = datetime.now() print "TIME ",iteration,':' , end - start iteration = iteration + 1 In the result I can check that in each iteration the time is bigger. The first iteration has time of 1.37s, then the time increases and the 19 iteration has time of 5.83 s! TIME 0 : 0:00:01.376392 TIME 1 : 0:00:01.663250 TIME 2 : 0:00:01.978639 TIME 3 : 0:00:02.319939 TIME 4 : 0:00:02.618213 TIME 5 : 0:00:02.723846 TIME 6 : 0:00:02.584007 TIME 7 : 0:00:02.868877 TIME 8 : 0:00:03.051937 TIME 9 : 0:00:03.389757 TIME 10 : 0:00:03.503036 TIME 11 : 0:00:03.563154 TIME 12 : 0:00:04.191539 TIME 13 : 0:00:04.274464 TIME 14 : 0:00:04.813206 TIME 15 : 0:00:04.677002 TIME 16 : 0:00:04.995708 TIME 17 : 0:00:05.126811 TIME 18 : 0:00:05.571279 TIME 19 : 0:00:05.832840 Why is happend this? Thanks in advance for your attention. Cheers Rosa ---------------------------------------------------------------------- Comment By: Rosa Robles (marobles) Date: 2011-07-20 08:32 Message: I didn't know profiler tool, thanks very much, Oleg!! I'm agree with you source of problem, in postgres it spends almost all time in method 'execute' of 'psycopg2._psycopg.cursor' objects however in mysql it spends almost all time in method 'query' of '_mysql.connection' objects. The problem is in the use of database, a lots of operations to database spends a lots time. Thanks very much, your help has been very useful to me. ---------------------------------------------------------------------- Comment By: Oleg Broytman (phd) Date: 2011-07-19 19:09 Message: Well, I ran it myself: python -m cProfile -s cumulative test_sql_object_by_object.py. The results is 5089432 function calls (4987267 primitive calls) in 82.498 CPU seconds Ordered by: cumulative time ncalls tottime percall cumtime percall filename:lineno(function) 1 0.001 0.001 82.498 82.498 {execfile} 1 0.001 0.001 82.497 82.497 test_sql_object_by_object.py:3(<module>) 1 0.324 0.324 82.115 82.115 test_sql_object_by_object.py:50(select_examples) 20000 0.295 0.000 77.778 0.004 sresults.py:126(__getitem__) 20000 0.442 0.000 75.925 0.004 sresults.py:175(__iter__) 20000 0.107 0.000 69.318 0.003 sresults.py:181(lazyIter) 20000 0.150 0.000 69.076 0.003 dbconnection.py:470(iterSelect) 20000 0.202 0.000 68.665 0.003 dbconnection.py:705(__init__) 20001 0.085 0.000 60.550 0.003 sqliteconnection.py:194(_executeRetry) 20001 60.465 0.003 60.465 0.003 {method 'execute' of 'pysqlite2.dbapi2.Cursor' objects} 20000 0.156 0.000 7.846 0.000 dbconnection.py:485(queryForSelect) 40000 0.332 0.000 5.945 0.000 dbconnection.py:719(next) 40000 0.170 0.000 5.601 0.000 dbconnection.py:670(sqlrepr) 140000/40000 0.584 0.000 5.430 0.000 converters.py:198(sqlrepr) 20000 1.305 0.000 4.802 0.000 sqlbuilder.py:613(__sqlrepr__) 20000 0.399 0.000 4.536 0.000 main.py:878(get) 20000 0.205 0.000 3.503 0.000 main.py:1373(selectBy) 20000 0.182 0.000 2.920 0.000 main.py:915(_init) 20000 0.655 0.000 2.735 0.000 sresults.py:42(queryForSelect) 140000 0.679 0.000 2.704 0.000 sqlbuilder.py:215(tablesUsedSet) 40000 0.931 0.000 2.620 0.000 sresults.py:9(__init__) 20000 0.440 0.000 2.373 0.000 main.py:1154(_SO_selectInit) 220568 0.660 0.000 1.967 0.000 {getattr} 80000 0.776 0.000 1.950 0.000 col.py:503(to_python) 140000 1.078 0.000 1.793 0.000 sqlbuilder.py:194(tablesUsedSet) 20000 0.465 0.000 1.699 0.000 dbconnection.py:641(_SO_columnClause) 20000 0.183 0.000 1.492 0.000 sresults.py:89(clone) 80000 0.446 0.000 1.431 0.000 sqlbuilder.py:391(__getattr__) 100024 0.597 0.000 1.173 0.000 dbconnection.py:896(__get__) 564108 1.073 0.000 1.073 0.000 {isinstance} The entire program took 80 seconds, of which 60 seconds were spend in method 'execute' of 'pysqlite2.dbapi2.Cursor' (I used sqlite). Not an SQLObject fault. You can run a profiler yourself sorting by different column. I'd like to hear your interpretation. ---------------------------------------------------------------------- Comment By: Oleg Broytman (phd) Date: 2011-07-19 17:21 Message: To stop cache culling I added connection.cache = CacheSet(cullFrequency=10**6) to your test program. It didn't help. So it seems cache culling is not the culprit. There is a need to do a deeper investigation. Can you run a python profiler over your test(s)? ---------------------------------------------------------------------- Comment By: Rosa Robles (marobles) Date: 2011-07-19 10:09 Message: if we review the results, after read a lots of records selectBy takes more times, in the first iteration is almost zero but in 20 iteration is bigger. If you do the example, and you takes the times without to call to expireAll() or clear(), you can check that the time c for iteration in range(20): start = datetime.now() for key in range(1000): person = Person.selectBy(firstName='name%s%s' % (iteration,key))[0] end = datetime.now() print "ITERATION ",iteration, "TIME", end-start Person.sqlmeta.expireAll() sqlhub.getConnection().expireAll() connection.cache.clear() ---------------------------------------------------------------------- Comment By: Oleg Broytman (phd) Date: 2011-07-18 19:50 Message: time_end-time_start are consistently almost zero, so selectBy doesn't take time, right? ---------------------------------------------------------------------- Comment By: Rosa Robles (marobles) Date: 2011-07-18 08:36 Message: The program takes time only from the selectby operation for key in range(1000): time_start = datetime.now() person = Person.selectBy(firstName='name%s%s' %(iteration,key))[0] time_end = datetime.now() times.append(time_end-time_start) I attach the example to you can read better If we review the results, the selectBy method takes times random in iteration, but also each iteration's time grows up. I think the problem is in the execution of cull process when delete expiredCache values, what do you think? In my real program do not use select in mass but it can acumulate a lots operations of select in the time, then we have problems of memory and we must restart the application. May be this situation is the source of our problem with the memory. ---------------------------------------------------------------------- Comment By: Oleg Broytman (phd) Date: 2011-07-15 19:14 Message: Min/max/avg times are almost zero, so it seems the only place the program spends time is calling .expireAll() and cache.clear(), right? ---------------------------------------------------------------------- Comment By: Rosa Robles (marobles) Date: 2011-07-15 08:52 Message: Thanks Oleg. I'm using SQLObject 1.1.1, Python2.6, Postgres 8.4 Ok, I change the code to takes more times. for iteration in range(20): start = datetime.now() acum = timedelta(microseconds=0) times = [] for key in range(1000): time_start = datetime.now() person = Person.selectBy(firstName='name%s%s' % (iteration,key))[0] time_end = datetime.now() times.append(time_end-time_start) acum = acum + (time_end-time_start) end = datetime.now() print "ITERATION ",iteration,"time",end-start print " First Key ->", times[0] print " Last Key ->",times[999] print " Key ->",times.index(max(times)), " Max Time ->", max(times) print " Key ->",times.index(min(times)), " Min Time ->", min(times) print " avg ->",acum/999 Person.sqlmeta.expireAll() for k in connection.cache.caches.keys(): connection.cache.caches[k].expireAll() sqlhub.getConnection().expireAll() connection.cache.clear() gc.collect() And the result is: ITERATION 0 time 0:00:01.302290 First Key -> 0:00:00.001555 Last Key -> 0:00:00.001445 Key -> 11 Max Time -> 0:00:00.003216 Key -> 36 Min Time -> 0:00:00.001115 avg -> 0:00:00.001287 ITERATION 1 time 0:00:01.621580 First Key -> 0:00:00.001879 Last Key -> 0:00:00.001734 Key -> 924 Max Time -> 0:00:00.009572 Key -> 22 Min Time -> 0:00:00.001076 avg -> 0:00:00.001606 ITERATION 2 time 0:00:01.851719 First Key -> 0:00:00.002328 Last Key -> 0:00:00.002064 Key -> 970 Max Time -> 0:00:00.002544 Key -> 22 Min Time -> 0:00:00.001306 avg -> 0:00:00.001836 ITERATION 3 time 0:00:02.040802 First Key -> 0:00:00.002435 Last Key -> 0:00:00.002376 Key -> 557 Max Time -> 0:00:00.009674 Key -> 25 Min Time -> 0:00:00.001538 avg -> 0:00:00.002026 ITERATION 4 time 0:00:02.427911 First Key -> 0:00:00.002906 Last Key -> 0:00:00.002065 Key -> 774 Max Time -> 0:00:00.003263 Key -> 7 Min Time -> 0:00:00.001763 avg -> 0:00:00.002413 ITERATION 5 time 0:00:02.768819 First Key -> 0:00:00.003051 Last Key -> 0:00:00.002319 Key -> 920 Max Time -> 0:00:00.007694 Key -> 11 Min Time -> 0:00:00.002007 avg -> 0:00:00.002753 ITERATION 6 time 0:00:02.537283 First Key -> 0:00:00.002676 Last Key -> 0:00:00.002549 Key -> 2 Max Time -> 0:00:00.003512 Key -> 132 Min Time -> 0:00:00.002318 avg -> 0:00:00.002523 ITERATION 7 time 0:00:02.723405 First Key -> 0:00:00.005272 Last Key -> 0:00:00.002788 Key -> 79 Max Time -> 0:00:00.007543 Key -> 12 Min Time -> 0:00:00.002457 avg -> 0:00:00.002709 ITERATION 8 time 0:00:02.947676 First Key -> 0:00:00.003161 Last Key -> 0:00:00.003028 Key -> 1 Max Time -> 0:00:00.006068 Key -> 31 Min Time -> 0:00:00.002683 avg -> 0:00:00.002933 ITERATION 9 time 0:00:03.781268 First Key -> 0:00:00.004271 Last Key -> 0:00:00.003416 Key -> 930 Max Time -> 0:00:00.011791 Key -> 5 Min Time -> 0:00:00.003029 avg -> 0:00:00.003765 ITERATION 10 time 0:00:03.842353 First Key -> 0:00:00.006544 Last Key -> 0:00:00.003394 Key -> 0 Max Time -> 0:00:00.006544 Key -> 4 Min Time -> 0:00:00.003171 avg -> 0:00:00.003826 ITERATION 11 time 0:00:03.361368 First Key -> 0:00:00.001509 Last Key -> 0:00:00.003626 Key -> 602 Max Time -> 0:00:00.009093 Key -> 9 Min Time -> 0:00:00.001089 avg -> 0:00:00.003346 ITERATION 12 time 0:00:03.581802 First Key -> 0:00:00.001511 Last Key -> 0:00:00.003912 Key -> 474 Max Time -> 0:00:00.009027 Key -> 1 Min Time -> 0:00:00.001117 avg -> 0:00:00.003566 ITERATION 13 time 0:00:03.797965 First Key -> 0:00:00.001833 Last Key -> 0:00:00.004118 Key -> 100 Max Time -> 0:00:00.005115 Key -> 9 Min Time -> 0:00:00.001126 avg -> 0:00:00.003782 ITERATION 14 time 0:00:04.147961 First Key -> 0:00:00.001851 Last Key -> 0:00:00.004362 Key -> 782 Max Time -> 0:00:00.013857 Key -> 16 Min Time -> 0:00:00.001186 avg -> 0:00:00.004132 ITERATION 15 time 0:00:04.251830 First Key -> 0:00:00.001538 Last Key -> 0:00:00.004611 Key -> 518 Max Time -> 0:00:00.009511 Key -> 9 Min Time -> 0:00:00.001114 avg -> 0:00:00.004236 ITERATION 16 time 0:00:04.487687 First Key -> 0:00:00.001541 Last Key -> 0:00:00.004994 Key -> 858 Max Time -> 0:00:00.009368 Key -> 9 Min Time -> 0:00:00.001120 avg -> 0:00:00.004472 ITERATION 17 time 0:00:04.703588 First Key -> 0:00:00.003440 Last Key -> 0:00:00.005104 Key -> 529 Max Time -> 0:00:00.008179 Key -> 8 Min Time -> 0:00:00.001105 avg -> 0:00:00.004688 ITERATION 18 time 0:00:05.300920 First Key -> 0:00:00.001851 Last Key -> 0:00:00.006987 Key -> 854 Max Time -> 0:00:00.007299 Key -> 9 Min Time -> 0:00:00.001181 avg -> 0:00:00.005285 ITERATION 19 time 0:00:06.168681 First Key -> 0:00:00.001880 Last Key -> 0:00:00.005577 Key -> 911 Max Time -> 0:00:00.009503 Key -> 9 Min Time -> 0:00:00.001119 avg -> 0:00:00.006152 ---------------------------------------------------------------------- Comment By: Oleg Broytman (phd) Date: 2011-07-14 18:56 Message: No idea what is going on. Let's investigate a little further. What version of SQLObject are you using? Can you add more prints inside the loop to see what part of the program takes time? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540673&aid=3366899&group_id=74338 |
From: SourceForge.net <no...@so...> - 2011-07-19 17:09:27
|
Support Requests item #3366899, was opened at 2011-07-14 11:40 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540673&aid=3366899&group_id=74338 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Private: No Submitted By: Rosa Robles (marobles) Assigned to: Oleg Broytman (phd) Summary: The speed of SQLObject is slower on the time Initial Comment: I had a test of a SQLObject and I had found a strange behaviour of SQLObject. On the time, the respond time is lesser. Here, I put a example of test code : from sqlobject.sqlbuilder import * connection = connectionForURI('postgresql://test:test@localhost/test_sql_object') sqlhub.processConnection = connection class Person(SQLObject): firstName = StringCol() middleInitial = StringCol(length=1, default=None) lastName = StringCol() iteration = 0 while 1: start = datetime.now() person_list = [] for key in range(1000): person = Person.selectBy(firstName='name%s%s' % (iteration,key))[0] person_list.append(person) for person in person_list: person.expire() del person del person_list sqlhub.processConnection.cache.clear() end = datetime.now() print "TIME ",iteration,':' , end - start iteration = iteration + 1 In the result I can check that in each iteration the time is bigger. The first iteration has time of 1.37s, then the time increases and the 19 iteration has time of 5.83 s! TIME 0 : 0:00:01.376392 TIME 1 : 0:00:01.663250 TIME 2 : 0:00:01.978639 TIME 3 : 0:00:02.319939 TIME 4 : 0:00:02.618213 TIME 5 : 0:00:02.723846 TIME 6 : 0:00:02.584007 TIME 7 : 0:00:02.868877 TIME 8 : 0:00:03.051937 TIME 9 : 0:00:03.389757 TIME 10 : 0:00:03.503036 TIME 11 : 0:00:03.563154 TIME 12 : 0:00:04.191539 TIME 13 : 0:00:04.274464 TIME 14 : 0:00:04.813206 TIME 15 : 0:00:04.677002 TIME 16 : 0:00:04.995708 TIME 17 : 0:00:05.126811 TIME 18 : 0:00:05.571279 TIME 19 : 0:00:05.832840 Why is happend this? Thanks in advance for your attention. Cheers Rosa ---------------------------------------------------------------------- >Comment By: Oleg Broytman (phd) Date: 2011-07-19 21:09 Message: Well, I ran it myself: python -m cProfile -s cumulative test_sql_object_by_object.py. The results is 5089432 function calls (4987267 primitive calls) in 82.498 CPU seconds Ordered by: cumulative time ncalls tottime percall cumtime percall filename:lineno(function) 1 0.001 0.001 82.498 82.498 {execfile} 1 0.001 0.001 82.497 82.497 test_sql_object_by_object.py:3(<module>) 1 0.324 0.324 82.115 82.115 test_sql_object_by_object.py:50(select_examples) 20000 0.295 0.000 77.778 0.004 sresults.py:126(__getitem__) 20000 0.442 0.000 75.925 0.004 sresults.py:175(__iter__) 20000 0.107 0.000 69.318 0.003 sresults.py:181(lazyIter) 20000 0.150 0.000 69.076 0.003 dbconnection.py:470(iterSelect) 20000 0.202 0.000 68.665 0.003 dbconnection.py:705(__init__) 20001 0.085 0.000 60.550 0.003 sqliteconnection.py:194(_executeRetry) 20001 60.465 0.003 60.465 0.003 {method 'execute' of 'pysqlite2.dbapi2.Cursor' objects} 20000 0.156 0.000 7.846 0.000 dbconnection.py:485(queryForSelect) 40000 0.332 0.000 5.945 0.000 dbconnection.py:719(next) 40000 0.170 0.000 5.601 0.000 dbconnection.py:670(sqlrepr) 140000/40000 0.584 0.000 5.430 0.000 converters.py:198(sqlrepr) 20000 1.305 0.000 4.802 0.000 sqlbuilder.py:613(__sqlrepr__) 20000 0.399 0.000 4.536 0.000 main.py:878(get) 20000 0.205 0.000 3.503 0.000 main.py:1373(selectBy) 20000 0.182 0.000 2.920 0.000 main.py:915(_init) 20000 0.655 0.000 2.735 0.000 sresults.py:42(queryForSelect) 140000 0.679 0.000 2.704 0.000 sqlbuilder.py:215(tablesUsedSet) 40000 0.931 0.000 2.620 0.000 sresults.py:9(__init__) 20000 0.440 0.000 2.373 0.000 main.py:1154(_SO_selectInit) 220568 0.660 0.000 1.967 0.000 {getattr} 80000 0.776 0.000 1.950 0.000 col.py:503(to_python) 140000 1.078 0.000 1.793 0.000 sqlbuilder.py:194(tablesUsedSet) 20000 0.465 0.000 1.699 0.000 dbconnection.py:641(_SO_columnClause) 20000 0.183 0.000 1.492 0.000 sresults.py:89(clone) 80000 0.446 0.000 1.431 0.000 sqlbuilder.py:391(__getattr__) 100024 0.597 0.000 1.173 0.000 dbconnection.py:896(__get__) 564108 1.073 0.000 1.073 0.000 {isinstance} The entire program took 80 seconds, of which 60 seconds were spend in method 'execute' of 'pysqlite2.dbapi2.Cursor' (I used sqlite). Not an SQLObject fault. You can run a profiler yourself sorting by different column. I'd like to hear your interpretation. ---------------------------------------------------------------------- Comment By: Oleg Broytman (phd) Date: 2011-07-19 19:21 Message: To stop cache culling I added connection.cache = CacheSet(cullFrequency=10**6) to your test program. It didn't help. So it seems cache culling is not the culprit. There is a need to do a deeper investigation. Can you run a python profiler over your test(s)? ---------------------------------------------------------------------- Comment By: Rosa Robles (marobles) Date: 2011-07-19 12:09 Message: if we review the results, after read a lots of records selectBy takes more times, in the first iteration is almost zero but in 20 iteration is bigger. If you do the example, and you takes the times without to call to expireAll() or clear(), you can check that the time c for iteration in range(20): start = datetime.now() for key in range(1000): person = Person.selectBy(firstName='name%s%s' % (iteration,key))[0] end = datetime.now() print "ITERATION ",iteration, "TIME", end-start Person.sqlmeta.expireAll() sqlhub.getConnection().expireAll() connection.cache.clear() ---------------------------------------------------------------------- Comment By: Oleg Broytman (phd) Date: 2011-07-18 21:50 Message: time_end-time_start are consistently almost zero, so selectBy doesn't take time, right? ---------------------------------------------------------------------- Comment By: Rosa Robles (marobles) Date: 2011-07-18 10:36 Message: The program takes time only from the selectby operation for key in range(1000): time_start = datetime.now() person = Person.selectBy(firstName='name%s%s' %(iteration,key))[0] time_end = datetime.now() times.append(time_end-time_start) I attach the example to you can read better If we review the results, the selectBy method takes times random in iteration, but also each iteration's time grows up. I think the problem is in the execution of cull process when delete expiredCache values, what do you think? In my real program do not use select in mass but it can acumulate a lots operations of select in the time, then we have problems of memory and we must restart the application. May be this situation is the source of our problem with the memory. ---------------------------------------------------------------------- Comment By: Oleg Broytman (phd) Date: 2011-07-15 21:14 Message: Min/max/avg times are almost zero, so it seems the only place the program spends time is calling .expireAll() and cache.clear(), right? ---------------------------------------------------------------------- Comment By: Rosa Robles (marobles) Date: 2011-07-15 10:52 Message: Thanks Oleg. I'm using SQLObject 1.1.1, Python2.6, Postgres 8.4 Ok, I change the code to takes more times. for iteration in range(20): start = datetime.now() acum = timedelta(microseconds=0) times = [] for key in range(1000): time_start = datetime.now() person = Person.selectBy(firstName='name%s%s' % (iteration,key))[0] time_end = datetime.now() times.append(time_end-time_start) acum = acum + (time_end-time_start) end = datetime.now() print "ITERATION ",iteration,"time",end-start print " First Key ->", times[0] print " Last Key ->",times[999] print " Key ->",times.index(max(times)), " Max Time ->", max(times) print " Key ->",times.index(min(times)), " Min Time ->", min(times) print " avg ->",acum/999 Person.sqlmeta.expireAll() for k in connection.cache.caches.keys(): connection.cache.caches[k].expireAll() sqlhub.getConnection().expireAll() connection.cache.clear() gc.collect() And the result is: ITERATION 0 time 0:00:01.302290 First Key -> 0:00:00.001555 Last Key -> 0:00:00.001445 Key -> 11 Max Time -> 0:00:00.003216 Key -> 36 Min Time -> 0:00:00.001115 avg -> 0:00:00.001287 ITERATION 1 time 0:00:01.621580 First Key -> 0:00:00.001879 Last Key -> 0:00:00.001734 Key -> 924 Max Time -> 0:00:00.009572 Key -> 22 Min Time -> 0:00:00.001076 avg -> 0:00:00.001606 ITERATION 2 time 0:00:01.851719 First Key -> 0:00:00.002328 Last Key -> 0:00:00.002064 Key -> 970 Max Time -> 0:00:00.002544 Key -> 22 Min Time -> 0:00:00.001306 avg -> 0:00:00.001836 ITERATION 3 time 0:00:02.040802 First Key -> 0:00:00.002435 Last Key -> 0:00:00.002376 Key -> 557 Max Time -> 0:00:00.009674 Key -> 25 Min Time -> 0:00:00.001538 avg -> 0:00:00.002026 ITERATION 4 time 0:00:02.427911 First Key -> 0:00:00.002906 Last Key -> 0:00:00.002065 Key -> 774 Max Time -> 0:00:00.003263 Key -> 7 Min Time -> 0:00:00.001763 avg -> 0:00:00.002413 ITERATION 5 time 0:00:02.768819 First Key -> 0:00:00.003051 Last Key -> 0:00:00.002319 Key -> 920 Max Time -> 0:00:00.007694 Key -> 11 Min Time -> 0:00:00.002007 avg -> 0:00:00.002753 ITERATION 6 time 0:00:02.537283 First Key -> 0:00:00.002676 Last Key -> 0:00:00.002549 Key -> 2 Max Time -> 0:00:00.003512 Key -> 132 Min Time -> 0:00:00.002318 avg -> 0:00:00.002523 ITERATION 7 time 0:00:02.723405 First Key -> 0:00:00.005272 Last Key -> 0:00:00.002788 Key -> 79 Max Time -> 0:00:00.007543 Key -> 12 Min Time -> 0:00:00.002457 avg -> 0:00:00.002709 ITERATION 8 time 0:00:02.947676 First Key -> 0:00:00.003161 Last Key -> 0:00:00.003028 Key -> 1 Max Time -> 0:00:00.006068 Key -> 31 Min Time -> 0:00:00.002683 avg -> 0:00:00.002933 ITERATION 9 time 0:00:03.781268 First Key -> 0:00:00.004271 Last Key -> 0:00:00.003416 Key -> 930 Max Time -> 0:00:00.011791 Key -> 5 Min Time -> 0:00:00.003029 avg -> 0:00:00.003765 ITERATION 10 time 0:00:03.842353 First Key -> 0:00:00.006544 Last Key -> 0:00:00.003394 Key -> 0 Max Time -> 0:00:00.006544 Key -> 4 Min Time -> 0:00:00.003171 avg -> 0:00:00.003826 ITERATION 11 time 0:00:03.361368 First Key -> 0:00:00.001509 Last Key -> 0:00:00.003626 Key -> 602 Max Time -> 0:00:00.009093 Key -> 9 Min Time -> 0:00:00.001089 avg -> 0:00:00.003346 ITERATION 12 time 0:00:03.581802 First Key -> 0:00:00.001511 Last Key -> 0:00:00.003912 Key -> 474 Max Time -> 0:00:00.009027 Key -> 1 Min Time -> 0:00:00.001117 avg -> 0:00:00.003566 ITERATION 13 time 0:00:03.797965 First Key -> 0:00:00.001833 Last Key -> 0:00:00.004118 Key -> 100 Max Time -> 0:00:00.005115 Key -> 9 Min Time -> 0:00:00.001126 avg -> 0:00:00.003782 ITERATION 14 time 0:00:04.147961 First Key -> 0:00:00.001851 Last Key -> 0:00:00.004362 Key -> 782 Max Time -> 0:00:00.013857 Key -> 16 Min Time -> 0:00:00.001186 avg -> 0:00:00.004132 ITERATION 15 time 0:00:04.251830 First Key -> 0:00:00.001538 Last Key -> 0:00:00.004611 Key -> 518 Max Time -> 0:00:00.009511 Key -> 9 Min Time -> 0:00:00.001114 avg -> 0:00:00.004236 ITERATION 16 time 0:00:04.487687 First Key -> 0:00:00.001541 Last Key -> 0:00:00.004994 Key -> 858 Max Time -> 0:00:00.009368 Key -> 9 Min Time -> 0:00:00.001120 avg -> 0:00:00.004472 ITERATION 17 time 0:00:04.703588 First Key -> 0:00:00.003440 Last Key -> 0:00:00.005104 Key -> 529 Max Time -> 0:00:00.008179 Key -> 8 Min Time -> 0:00:00.001105 avg -> 0:00:00.004688 ITERATION 18 time 0:00:05.300920 First Key -> 0:00:00.001851 Last Key -> 0:00:00.006987 Key -> 854 Max Time -> 0:00:00.007299 Key -> 9 Min Time -> 0:00:00.001181 avg -> 0:00:00.005285 ITERATION 19 time 0:00:06.168681 First Key -> 0:00:00.001880 Last Key -> 0:00:00.005577 Key -> 911 Max Time -> 0:00:00.009503 Key -> 9 Min Time -> 0:00:00.001119 avg -> 0:00:00.006152 ---------------------------------------------------------------------- Comment By: Oleg Broytman (phd) Date: 2011-07-14 20:56 Message: No idea what is going on. Let's investigate a little further. What version of SQLObject are you using? Can you add more prints inside the loop to see what part of the program takes time? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540673&aid=3366899&group_id=74338 |