Thread: [SQLObject] Postgres: DROP table CASCADE
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: Oleg B. <ph...@ph...> - 2004-11-29 16:55:29
|
Traceback (most recent call last): File "/usr/local/src/SQL/SQLObject-inheritance/tests/SQLObjectTest.py", line 131, in setUp c.dropTable(ifExists=True, cascade=True) File "/usr/local/lib/python2.3/site-packages/sqlobject/main.py", line 1150, in dropTable conn.dropTable(cls._table, cascade) File "/usr/local/lib/python2.3/site-packages/sqlobject/postgres/pgconnection.py", line 96, in dropTable self.query("DROP TABLE %s %s" % (tableName, File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 205, in query return self._runWithConnection(self._query, s) File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 126, in _runWithConnection val = meth(conn, *args) File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 202, in _query self._executeRetry(conn, conn.cursor(), s) File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 197, in _executeRetry return cursor.execute(query) ProgrammingError: ERROR: parser: parse error at or near "CASCADE" DROP TABLE so_validation CASCADE AFAII Postgres does not support CASCADE. Exactly opposite - it is MySQL who supports it... to some extent. MySQL silently ignores CASCADE. But Postgres actively opposes it. Can I remove dropTable() from sqlobject/postgres/pgconnection.py in the trunk? Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ian B. <ia...@co...> - 2004-11-29 17:01:52
|
What version of Postgres are you using? This might be a version issue there, as I'm pretty sure at least some versions of Postgres support CASCADE. Maybe we have to do a version check on the pg server, though I'm not really sure how to do that (some pg_ table, I guess). Oleg Broytmann wrote: > Traceback (most recent call last): > File "/usr/local/src/SQL/SQLObject-inheritance/tests/SQLObjectTest.py", line 131, in setUp > c.dropTable(ifExists=True, cascade=True) > File "/usr/local/lib/python2.3/site-packages/sqlobject/main.py", line 1150, in dropTable > conn.dropTable(cls._table, cascade) > File "/usr/local/lib/python2.3/site-packages/sqlobject/postgres/pgconnection.py", line 96, in dropTable > self.query("DROP TABLE %s %s" % (tableName, > File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 205, in query > return self._runWithConnection(self._query, s) > File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 126, in _runWithConnection > val = meth(conn, *args) > File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 202, in _query > self._executeRetry(conn, conn.cursor(), s) > File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 197, in _executeRetry > return cursor.execute(query) > ProgrammingError: ERROR: parser: parse error at or near "CASCADE" > > DROP TABLE so_validation CASCADE > > AFAII Postgres does not support CASCADE. Exactly opposite - it is > MySQL who supports it... to some extent. MySQL silently ignores CASCADE. > But Postgres actively opposes it. > > Can I remove dropTable() from sqlobject/postgres/pgconnection.py in > the trunk? > > Oleg. |
From: Oleg B. <ph...@ma...> - 2004-11-29 17:08:13
|
On Mon, Nov 29, 2004 at 10:58:26AM -0600, Ian Bicking wrote: > What version of Postgres are you using? 7.2 (7.2.1 - this is Debian GNU/Linux 3.0). Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Oleg B. <ph...@ph...> - 2004-11-29 17:25:59
|
On Mon, Nov 29, 2004 at 10:58:26AM -0600, Ian Bicking wrote: > Maybe we have to do a version check on the pg server, though > I'm not really sure how to do that (some pg_ table, I guess). SELECT version(); The result string is probably too version-dependent, I am afraid. My is # SELECT version(); version --------------------------------------------------------------- PostgreSQL 7.2.1 on i686-pc-linux-gnu, compiled by GCC 2.95.4 (1 row) Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Oleg B. <ph...@ph...> - 2004-11-29 18:01:09
Attachments:
pgconnection.py.patch
|
On Mon, Nov 29, 2004 at 10:58:26AM -0600, Ian Bicking wrote: > Maybe we have to do a version check on the pg server, though The atached patch does the job. I can commit it, if no one objects. PS. After fixing it I've got an amazing number of exceptions and failures during the test. It seems no one has ran the test suite for quite some time, at least on Postgres! Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ian B. <ia...@co...> - 2004-11-29 18:06:26
|
Oleg Broytmann wrote: > On Mon, Nov 29, 2004 at 10:58:26AM -0600, Ian Bicking wrote: > >>Maybe we have to do a version check on the pg server, though > > > The atached patch does the job. I can commit it, if no one objects. Can you move the server version into a method (serverVersion()), and use an if statement in dropTable (instead of or/and conditionals)? > PS. After fixing it I've got an amazing number of exceptions and > failures during the test. It seems no one has ran the test suite for > quite some time, at least on Postgres! I was just running it without problems. Actually there's a transaction problem that only occurs when I run all the tests in sequence, and I don't understand it. But otherwise it's fine. Maybe it's more problems with 7.2? -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: Oleg B. <ph...@ph...> - 2004-11-29 18:21:43
|
On Mon, Nov 29, 2004 at 12:03:03PM -0600, Ian Bicking wrote: > Can you move the server version into a method (serverVersion()) Certainly I can... but why? You'd like to ask the same version again and again? Or you want to ask for the version only one, but not in __init__? In the latter case it'd be better to implemen it as a property. > >PS. After fixing it I've got an amazing number of exceptions and > >failures during the test. It seems no one has ran the test suite for > >quite some time, at least on Postgres! > > I was just running it without problems. Actually there's a transaction > problem that only occurs when I run all the tests in sequence, and I > don't understand it. But otherwise it's fine. Maybe it's more problems > with 7.2? I think so. The first problem is ERROR: testClassCreate (__main__.AutoTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "test_sqlobject.py", line 700, in testClassCreate class AutoTest(SQLObject): File "/usr/local/lib/python2.3/site-packages/sqlobject/main.py", line 225, in __new__ newClass.addColumnsFromDatabase() File "/usr/local/lib/python2.3/site-packages/sqlobject/main.py", line 593, in addColumnsFromDatabase for columnDef in conn.columnsFromSchema(cls._table, cls): File "pgconnection.py", line 151, in columnsFromSchema File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 218, in queryAll return self._runWithConnection(self._queryAll, s) File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 126, in _runWithConnection val = meth(conn, *args) File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 211, in _queryAll self._executeRetry(conn, c, s) File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 197, in _executeRetry return cursor.execute(query) ProgrammingError: ERROR: parser: parse error at or near "(" SELECT pg_catalog.pg_get_constraintdef(oid) as condef FROM pg_catalog.pg_constraint r WHERE r.conrelid = 'auto_test'::regclass AND r.contype = 'f' And most other exceptions are, probably, the result of unclean exit from the method: ERROR: testGet (__main__.DeleteSelectTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/src/SQL/SQLObject-inheritance/tests/SQLObjectTest.py", line 144, in setUp c.createTable(ifNotExists=True) File "/usr/local/lib/python2.3/site-packages/sqlobject/main.py", line 1161, in createTable conn.createTable(cls) File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 349, in createTable self.query(self.createTableSQL(soClass)) File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 205, in query return self._runWithConnection(self._query, s) File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 126, in _runWithConnection val = meth(conn, *args) File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 202, in _query self._executeRetry(conn, conn.cursor(), s) File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 197, in _executeRetry return cursor.execute(query) ProgrammingError: ERROR: Relation 'test_s_o1_id_seq' already exists CREATE TABLE test_s_o1 ( id SERIAL PRIMARY KEY, passwd VARCHAR(10), name_col VARCHAR(50) ) except for the only failure: FAIL: Raise an error if a class is defined more than once. ---------------------------------------------------------------------- Traceback (most recent call last): File "test_sqlobject.py", line 37, in testErrorOnDuplicateClassDefinition self.assertEqual(str(err), "class Duplicate is already in the registry") File "/usr/local/lib/python2.3/unittest.py", line 302, in failUnlessEqual raise self.failureException, \ AssertionError: "class Duplicate is already in the registry (other class is <class '__main__.Duplicate'>, from the module __main__ in test_sqlobject.py; attempted new class is <class '__main__.Duplicate'>, from the module __main__ in test_sqlobject.py)" != 'class Duplicate is already in the registry' Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ian B. <ia...@co...> - 2004-11-29 18:28:12
|
Oleg Broytmann wrote: > On Mon, Nov 29, 2004 at 12:03:03PM -0600, Ian Bicking wrote: > >>Can you move the server version into a method (serverVersion()) > > > Certainly I can... but why? You'd like to ask the same version again > and again? > Or you want to ask for the version only one, but not in __init__? In > the latter case it'd be better to implemen it as a property. You could cache the result, but in many cases that query need never be run, so it shouldn't happen on instantiation. >>>PS. After fixing it I've got an amazing number of exceptions and >>>failures during the test. It seems no one has ran the test suite for >>>quite some time, at least on Postgres! >> >>I was just running it without problems. Actually there's a transaction >>problem that only occurs when I run all the tests in sequence, and I >>don't understand it. But otherwise it's fine. Maybe it's more problems >>with 7.2? > > > I think so. The first problem is > > ERROR: testClassCreate (__main__.AutoTest) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "test_sqlobject.py", line 700, in testClassCreate > class AutoTest(SQLObject): > File "/usr/local/lib/python2.3/site-packages/sqlobject/main.py", line 225, in __new__ > newClass.addColumnsFromDatabase() > File "/usr/local/lib/python2.3/site-packages/sqlobject/main.py", line 593, in addColumnsFromDatabase > for columnDef in conn.columnsFromSchema(cls._table, cls): > File "pgconnection.py", line 151, in columnsFromSchema > File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 218, in queryAll > return self._runWithConnection(self._queryAll, s) > File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 126, in _runWithConnection > val = meth(conn, *args) > File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 211, in _queryAll > self._executeRetry(conn, c, s) > File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 197, in _executeRetry > return cursor.execute(query) > ProgrammingError: ERROR: parser: parse error at or near "(" > > > SELECT pg_catalog.pg_get_constraintdef(oid) as condef > FROM pg_catalog.pg_constraint r > WHERE r.conrelid = 'auto_test'::regclass AND r.contype = 'f' I don't believe there's any "pg_catalog" in 7.2; I believe pg_catalog is a schema (a separate table/function namespace), and schemas weren't introduced until after 7.2. In that case, maybe just removing "pg_catalog." will fix it (if the version is 7.2). > And most other exceptions are, probably, the result of unclean exit from the method: > > ERROR: testGet (__main__.DeleteSelectTest) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/local/src/SQL/SQLObject-inheritance/tests/SQLObjectTest.py", line 144, in setUp > c.createTable(ifNotExists=True) > File "/usr/local/lib/python2.3/site-packages/sqlobject/main.py", line 1161, in createTable > conn.createTable(cls) > File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 349, in createTable > self.query(self.createTableSQL(soClass)) > File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 205, in query > return self._runWithConnection(self._query, s) > File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 126, in _runWithConnection > val = meth(conn, *args) > File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 202, in _query > self._executeRetry(conn, conn.cursor(), s) > File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 197, in _executeRetry > return cursor.execute(query) > ProgrammingError: ERROR: Relation 'test_s_o1_id_seq' already exists > > CREATE TABLE test_s_o1 ( > id SERIAL PRIMARY KEY, > passwd VARCHAR(10), > name_col VARCHAR(50) > ) That's must be something left over; generally I haven't had problems with that (the tests are supposed to clean up after themselves), but it could happen. > except for the only failure: > > FAIL: Raise an error if a class is defined more than once. > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "test_sqlobject.py", line 37, in testErrorOnDuplicateClassDefinition > self.assertEqual(str(err), "class Duplicate is already in the registry") > File "/usr/local/lib/python2.3/unittest.py", line 302, in failUnlessEqual > raise self.failureException, \ > AssertionError: "class Duplicate is already in the registry (other class is <class '__main__.Duplicate'>, from the module __main__ in test_sqlobject.py; attempted new class is <class '__main__.Duplicate'>, from the module __main__ in test_sqlobject.py)" != 'class Duplicate is already in the registry' I just fixed this one today, if you svn up it should be gone. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: Oleg B. <ph...@ph...> - 2004-11-29 19:17:41
Attachments:
pgconnection.py.patch
|
On Mon, Nov 29, 2004 at 12:24:50PM -0600, Ian Bicking wrote: > You could cache the result, but in many cases that query need never be > run, so it shouldn't happen on instantiation. What about the attached version? > I just fixed this one today, if you svn up it should be gone. Yes, that fixed the problem. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ian B. <ia...@co...> - 2004-11-29 21:11:04
|
Oleg Broytmann wrote: > On Mon, Nov 29, 2004 at 12:24:50PM -0600, Ian Bicking wrote: > >>You could cache the result, but in many cases that query need never be >>run, so it shouldn't happen on instantiation. > > > What about the attached version? Yes, that looks good. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: Oleg B. <ph...@ph...> - 2004-11-29 21:30:53
|
On Mon, Nov 29, 2004 at 03:07:41PM -0600, Ian Bicking wrote: > Oleg Broytmann wrote: > >On Mon, Nov 29, 2004 at 12:24:50PM -0600, Ian Bicking wrote: > > > >>You could cache the result, but in many cases that query need never be > >>run, so it shouldn't happen on instantiation. > > > > What about the attached version? > > Yes, that looks good. Commited. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Oleg B. <ph...@ph...> - 2004-11-29 18:28:08
|
On Mon, Nov 29, 2004 at 12:03:03PM -0600, Ian Bicking wrote: > >PS. After fixing it I've got an amazing number of exceptions and > >failures during the test. It seems no one has ran the test suite for > >quite some time, at least on Postgres! > > I was just running it without problems. BTW, how have yoy ran it at all? $ python -O test.py -d postgres Traceback (most recent call last): File "test.py", line 1372, in ? setDatabaseType(db) File "/usr/local/src/SQL/SQLObject/tests/SQLObjectTest.py", line 174, in setDatabaseType raise KeyError, 'No connection by the type %s is known' % t KeyError: 'No connection by the type is known' Of course. if arg.startswith('-d'): dbs.append(arg[2:]) dbs is now [["postgres"]] instead of ["postgres"]. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ian B. <ia...@co...> - 2004-11-29 18:34:52
|
Oleg Broytmann wrote: > On Mon, Nov 29, 2004 at 12:03:03PM -0600, Ian Bicking wrote: > >>>PS. After fixing it I've got an amazing number of exceptions and >>>failures during the test. It seems no one has ran the test suite for >>>quite some time, at least on Postgres! >> >>I was just running it without problems. > > > BTW, how have yoy ran it at all? > > $ python -O test.py -d postgres python test.py -dpostgres it's not very flexible with its command-line arguments. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: Oleg B. <ph...@ph...> - 2004-11-29 18:47:43
|
On Mon, Nov 29, 2004 at 12:31:31PM -0600, Ian Bicking wrote: > python test.py -dpostgres > it's not very flexible with its command-line arguments. I've made it much more flexible using getopt. Please look at main() at http://svn.colorstudy.com/home/phd/SQLObject/inheritance/tests/test_sqlobject.py PS. I renamed test.py to test_sqlobject.py to import from it. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ian B. <ia...@co...> - 2004-11-29 18:50:52
|
Oleg Broytmann wrote: > On Mon, Nov 29, 2004 at 12:31:31PM -0600, Ian Bicking wrote: > >>python test.py -dpostgres >>it's not very flexible with its command-line arguments. > > > I've made it much more flexible using getopt. Please look at main() at > > http://svn.colorstudy.com/home/phd/SQLObject/inheritance/tests/test_sqlobject.py > > PS. I renamed test.py to test_sqlobject.py to import from it. Thanks; if you want to merge that over into the trunk, please do. The rename is probably a good idea. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: Oleg B. <ph...@ph...> - 2004-11-29 19:15:13
|
On Mon, Nov 29, 2004 at 12:47:32PM -0600, Ian Bicking wrote: > >http://svn.colorstudy.com/home/phd/SQLObject/inheritance/tests/test_sqlobject.py > > > >PS. I renamed test.py to test_sqlobject.py to import from it. > > Thanks; if you want to merge that over into the trunk, please do. The > rename is probably a good idea. Done. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Sidnei da S. <si...@aw...> - 2004-11-30 11:28:17
|
On Mon, Nov 29, 2004 at 09:47:37PM +0300, Oleg Broytmann wrote: | On Mon, Nov 29, 2004 at 12:31:31PM -0600, Ian Bicking wrote: | > python test.py -dpostgres | > it's not very flexible with its command-line arguments. | | I've made it much more flexible using getopt. Please look at main() at | | http://svn.colorstudy.com/home/phd/SQLObject/inheritance/tests/test_sqlobject.py | | PS. I renamed test.py to test_sqlobject.py to import from it. What's wrong with optparse? Do we still need to support Python 2.2? -- Sidnei da Silva <si...@aw...> http://awkly.org - dreamcatching :: making your dreams come true http://www.enfoldsystems.com http://plone.org/about/team#dreamcatcher The meta-Turing test counts a thing as intelligent if it seeks to devise and apply Turing tests to objects of its own creation. -- Lew Mammel, Jr. |
From: Oleg B. <ph...@ma...> - 2004-11-30 11:48:59
|
On Tue, Nov 30, 2004 at 09:27:23AM -0200, Sidnei da Silva wrote: > What's wrong with optparse? It's too verbose for such a small task. What's wrong with getopt? It does its job well. > Do we still need to support Python 2.2? We need. Documentation states SQLObject support Python 2.2+. Python 2.2.3 is not so old yet, why broke support? Not all are living on the bleeding edge. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ian B. <ia...@co...> - 2004-11-30 17:48:17
|
Sidnei da Silva wrote: > On Mon, Nov 29, 2004 at 09:47:37PM +0300, Oleg Broytmann wrote: > | On Mon, Nov 29, 2004 at 12:31:31PM -0600, Ian Bicking wrote: > | > python test.py -dpostgres > | > it's not very flexible with its command-line arguments. > | > | I've made it much more flexible using getopt. Please look at main() at > | > | http://svn.colorstudy.com/home/phd/SQLObject/inheritance/tests/test_sqlobject.py > | > | PS. I renamed test.py to test_sqlobject.py to import from it. > > What's wrong with optparse? Do we still need to support Python 2.2? Yes, we should still support Python 2.2, but we could also include optparse/optik as part of the package. We could either require people to install it (at least if they want run tests), or include it in the tarball and fit it into setup.py, or just include it in the source distribution (under like sqlobject/python24/optparse). At some point we should be using the logging module as well, which raises the same issue. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: Martin d'A. <Mar...@s2...> - 2004-11-30 03:00:29
|
Hi, I think I have found a memory leak. I have a loop that inserts hundreds of thousands of rows in my table, and the memory usage grows eventhough I do not keep a handle to the instances I am creating. For example, the following program will use more memory when you tell it to store more rows in the database: #!/usr/bin/env python import sys from sqlobject import * class Persons(SQLObject): name = StringCol(length=4) def create_table(conn): Persons._cacheValues = False Persons._connection = conn Persons.dropTable(ifExists=True) Persons.createTable() def fill_table(size): for i in xrange(int(size)): p = Persons(name='Joe'+`i`) if __name__ == '__main__': size = sys.argv[1] conn = connectionForURI('mysql://user:passwd@server/test') create_table(conn) fill_table(size) At the prompt, just type "persons.py <number>". The bigger the <number>, the more memory is used. Is there a solution? Martin |
From: Ryan H. <rh...@sh...> - 2004-11-30 17:26:25
|
* Martin d'Anjou <Mar...@s2...> [2004-11-29 21:01]: > Hi, > > I think I have found a memory leak. I have a loop that inserts hundreds of > It is not a memory leak. I thought the same thing, but found out that SQLObject caches object creation. Hence, python's memory footprint grows with each insert. in main.py: def _SO_finishCreate(self, id=None): <snip> ... cache.created(id, self.__class__, self) then in cache.py: def created(self, id, obj): if self.doCache: self.cache[id] = obj else: self.expiredCache[id] = ref(obj) You can flush the cache as follows: table._connection.cache.clear() In your example code: def fill_table(size): for i in xrange(int(size)): p = Persons(name='Joe'+`i`) Persons._connection.cache.clear() or you can delay until all inserts are done: def fill_table(size): for i in xrange(int(size)): p = Persons(name='Joe'+`i`) Persons._connection.cache.clear() On a related note, you will notice that in addition to the caching of the object, immediately following the insert, SQLObject will issue a select to fetch the values to create an instance in _init(). This degrades mysql insert performance. It would be nice to be able to toggle caching as well as instance _init. Ryan Harper |
From: Martin d'A. <Mar...@s2...> - 2004-11-30 18:05:21
|
Thanks for the informative reply! > It would be nice to be able to toggle caching as well as instance _init. I agree! Martin |
From: Ryan H. <rh...@sh...> - 2004-11-30 20:17:39
|
* Leif K-Brooks <eu...@ec...> [2004-11-30 12:37]: > Ryan Harper wrote: > > >It would be nice to be able to toggle caching > > > You can, set the _cacheValues attribute to False. See > <URL:http://sqlobject.org/docs/SQLObject.html#sqlobject-class-specifying-your-class>. from main.py: # The _cacheValues attribute controls if you cache # values fetched from the database. We make sure # it's set (default 1). This controls whether SQLObject caches results, not whether it will cache object creation. A subtle distinction that isnt indicated in the documentation. In any case, I did set this value and observed no reduction in memory footprint. If it was unclear before, I would like to be able to toggle the following: 1. caching of newly created objects (inserts) 2. Avoid issuing the subseqent select to initialize newly created objects (_init() calls selectOne()) Ryan Harper |
From: Mike T. <mik...@da...> - 2004-11-30 22:31:27
|
Ryan Harper wrote: > * Martin d'Anjou <Mar...@s2...> [2004-11-29 21:01]: > >>Hi, >> >>I think I have found a memory leak. I have a loop that inserts hundreds of >> > > > It is not a memory leak. I thought the same thing, but found out that > SQLObject caches object creation. Hence, python's memory footprint > grows with each insert. > Seems to be that this question and your response should be in the FAQ. -- Mike |
From: Martin d'A. <Mar...@s2...> - 2004-11-30 23:05:58
|
On Wed, 1 Dec 2004, Mike Thompson wrote: > Ryan Harper wrote: > > * Martin d'Anjou <Mar...@s2...> [2004-11-29 21:01]: > >>Hi, > >> > >>I think I have found a memory leak. I have a loop that inserts hundreds of > > It is not a memory leak. I thought the same thing, but found out that > > SQLObject caches object creation. Hence, python's memory footprint > > grows with each insert. > Seems to be that this question and your response should be in the FAQ. Along with the _connection.cache.clear() trick. Martin |