Re: [sqlalchemy] Expunge
On 2010-09-25 2:29 PM, Mark Erbaugh wrote: If I retrieve data strictly for reporting or other read-only use, e.g. the session will not be used to update data, should I expunge the objects returned by the query from the session? If I just let the session object go out of scope is that sufficient? If you're not modifying the objects, then you don't have to do anything at all. If you are modifying them, then as long as you don't call commit() on the session, the changes will be discarded when the session is deleted. (That's assuming you have autocommit==False). (Also, I think go out of scope is ambiguous in Python, where what really matters is whether there are other references to the session. Only when the last reference is removed is the session garbage-collected and the changes will discarded/rolled-back. Having a local variable referencing the session go out of scope does nothing if there are other non-local references to the same session. But you probably know all that. :) ) -- Peter Hansen -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] Re: SQLite: Rolling back DDL requests
On Aug 14, 11:07 am, Michael Bayer mike...@zzzcomputing.com wrote: In addition, isolation_level=None with pysqlite disables the DBAPIs entire transactional system. SQLAlchemy relies upon this system to handle proper transactional behavior. So I consider this a pysqlite bug, and they should offer a mode by which there is no implicit commit for CREATE TABLE. Michael, I don't doubt that you're right, but the puzzling thing (for me and, I think, Torsen) is that (if you set echo='debug') you see a BEGIN and ROLLBACK statement apparently being issued through the DBAPI layer, and if there's an implicit COMMIT going on we don't actually see it and don't understand why isolation_level=None isn't preventing it as it apparently does in the other case (test02). I suspect this is because with the logging on, we aren't actually seeing the operations performed, but merely sqlalchemy's report of what it is about to ask for. If the DBAPI is doing something under the covers, we don't know what and therefore can't find a workaround. To be clear, in test02 I believe we're effectively telling sqlite3 BEGIN; CREATE TABLE ...; ROLLBACK, and in test03 (with the same isolation_level setting) that's exactly what the logging reports is happening, yet the behaviour is different. (I was hoping to put some debugging in the DBAPI layer but unfortunately that's a C extension so harder to deal with. Maybe there's also some feature in sqlite3 itself (not the Python module) which can be configured for debug purposes to show what's really happening here.) -- Peter Hansen Engenuity Corporation -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] Re: SQLite: Rolling back DDL requests
On Jun 24, 1:23 pm, Michael Bayer mike...@zzzcomputing.com wrote:
On Jun 24, 2010, at 12:35 PM, Torsten Landschoff wrote:
That's what I thought but it does not cure my problem.
e.raw_connect().isolation_levelis in fact None, but the rollback is not
done anyway. :-(
its passing it through.dont know what else we can do there
I ran into this myself today and after struggling for a few hours I
came across this thread. I then ended up creating a test case to
reproduce the problem and it suggests the problem stems from some
behaviour of transactions or of the engine.base.Connection class. I
don't quite know what to make of it yet, but I think it shows that the
effect of passing it through is being counteracted by something
else. I ran this on Python 2.6.5 with SA 0.6.3 on Windows.
'''Test showing unexpected behaviour with sqlalchemy and sqlite3 and
isolation_level settings. The test creates one table outside of
a transaction (to detect potential problems with the test not
executing
properly) then creates a second table inside a transaction which it
immediately rolls back.
test01() fails basically as expected, since the sqlite3 DBAPI layer
appears to need isolation_level==None to properly roll back DDL
statements.
test02() succeeds because isolation_level==None now. This test and
test01()
both use a connection from engine.raw_connection(), which is a
sqlalchemy.pool._ConnectionFairy() object.
test03() tries again with isolation_level==None but using a
transaction
created from a connection returned by engine.connect(), which is a
sqlalchemy.engine.base.Connection() object. This test fails in spite
of the isolation_level setting.
'''
import unittest
from sqlalchemy import create_engine
DBPATH = 'sqlite://'
DDL = 'create table %s (id integer primary key)'
class TestCase(unittest.TestCase):
def setup(self, **kwargs):
self.engine = create_engine(DBPATH, **kwargs)
self.engine.execute(DDL % 'foo')
def rollback_raw(self):
conn = self.engine.raw_connection()
try:
conn.execute('begin')
conn.execute(DDL % 'bar')
raise ValueError
except ValueError:
conn.rollback()
def rollback_txn(self):
conn = self.engine.connect()
try:
txn = conn.begin()
conn.execute(DDL % 'bar')
raise ValueError
except ValueError:
txn.rollback()
def get_table_names(self):
conn = self.engine.raw_connection()
return [x[0] for x in conn.execute('select name from
sqlite_master')]
def test01(self):
'''use engine with default isolation_level'''
self.setup()
self.rollback_raw()
self.assertEqual(['foo'], self.get_table_names())
def test02(self):
'''use raw_connection with isolation_level None'''
self.setup(connect_args={'isolation_level': None})
self.rollback_raw()
self.assertEqual(['foo'], self.get_table_names())
def test03(self):
'''use transaction with isolation_level None'''
self.setup(connect_args={'isolation_level': None})
self.rollback_txn()
self.assertEqual(['foo'], self.get_table_names())
if __name__ == '__main__':
unittest.main()
--
Peter Hansen
Engenuity Corporation
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] Re: app memory leak - execute() with SA 0.5.2, PG 8.3, Psycopg2
Allen Bierbaum wrote: On Tue, Feb 24, 2009 at 4:44 AM, Chris Miles miles.ch...@gmail.com wrote: On Feb 22, 6:08 am, Allen Bierbaum abierb...@gmail.com wrote: Python 2.5 and later will free up garbage collected memory, handing it back to the system. Previous versions of Python would never free up memory (hence never shrink in size). Are you using Python 2.4? I am using Python 2.5. But now that I understand the issue better I have come up with a workaround. The biggest issue was that I didn't understand what I should be seeing as far as memory usage. Although your workaround may not be generally useful, it would still be nice for posterity (i.e. those searching through this thread in future) if you could summarize how you've actually addressed this issue to your satisfaction, however crude or unusual that might be. Thanks. :) -- Peter Hansen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Cannot abort wxPython thread with SQLAlchemy
Dominique wrote: On 10 juin, 02:38, Peter Hansen [EMAIL PROTECTED] wrote: As Python has no way to actually terminate a thread, can you explain what you mean by stop this thread? Are you simply cloning the code from the wxPython example, with the delayedresult.AbortEvent() object, and calling .set() on it? That's exactly what I do. My Abort button is linked to an abort function which calls abortEvent.set(), like in the demo. In the producer function, I launch the query. What I'd like to do is to be able to stop the thread, while the query is being done. Is it possible or am I trying to do something impossible ? As no one else has chimed in, I'll go out on a limb a bit and say that it's impossible. Python itself definitely doesn't have any way to forcibly kill a thread, at least not one that is buried in an external call (e.g. in the sqlite library). There is a mechanism that's been added in recent versions that can terminate (under certain conditions) pure Python code in another thread by asynchronously raising an exception: search for python asynchronous exception and make sure you understand the issues before trying to use it. If you could restructure your application so the long-running query occurs in a separate process, you could kill the process using operating system support for that, though perhaps not in a clean fashion. Aside from that, you don't have many options. What about changing the query so that it will return its results in increments, rather than all at once? If it's a long-running query but you can break it up that way, then the check event flag approach you're using would be able to work. -Peter --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Cannot abort wxPython thread with SQLAlchemy
Dominique wrote: I am using delayedresult (which is a class to do threading in wxPython) for a query with SQLAlchemy, using SQLite. I have an 'opened' session in the main App thread. I create another session under the delayedresult thread. When I try to stop this thread with a dedicated button, the thread doesn't abort and goes on till it sends the result. As Python has no way to actually terminate a thread, can you explain what you mean by stop this thread? Are you simply cloning the code from the wxPython example, with the delayedresult.AbortEvent() object, and calling .set() on it? -Peter --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
