Re: [sqlalchemy] PyODBCConnector dbapi question
On Fri, Apr 2, 2010 at 21:08, Bo Shi bs1...@gmail.com wrote: Hrm, some different errors pop up. I'll move the dialog to the ticket in question. http://www.sqlalchemy.org/trac/ticket/1757 Should be fixed now (hopefully). Could you test once more? Thanks, -- Gaëtan de Menten -- 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] Is it normal that session.query(...).autoflush(False) still issues UPDATEs?
Hey everyone, Is it the expected behavior that after querying an object with `session.query(...).autoflush(False)...` and modifying some of its fields still makes it issue UPDATE when a relation of the object is referenced? Let me illustrate what I mean precisely. First I query the Page class: page = session.query(Page).autoflush(False).filter_by(page_id=...).first() Next, I assign a new title for the page: page.title = new title Now the page also has the `path` property that is a relation on Paths table. As soon as I do: print page.path I see that SQLAlchemy issues an UPDATE statement for the page.title, even though the page was said to be autoflush=False. I am wondering if this is the expected behavior? While the page should not autoflush, the relation still uses the session with autoflush=True. Somehow the relation's autoflush overtakes the Page query's autoflush and an UPDATE is issed... I am using the latest SQLAlchemy-0.6beta3-py2.5. Sincerely, P.Krumins -- 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.
Re: [sqlalchemy] Firebird and rowcount
On Apr 9, 2010, at 4:51 PM, nekto0n wrote: Hi there! I'm now in the process of migrating from pure kinterbasdb to SQLAlchemy. Everything is fine except for speed of insertions and maybe updates. After some time of profiling I found out that a significant amount of time is spent on getting rowcount after execution. It takes about 5 seconds vs 41 spent on 3000 insertions themselves. That is 12%. Not much, but still. Digging further showed that rowcount attribute of kinterbasdb.Cursor is a getter, which remotely calles to Firebird Database. Here is the comment from _kicore_cursor.c source file: Determining rowcount is a fairly expensive operation that requires an isc_dsql_sql_info call. I wonder if there's any possible way to make getting rowcount optional or lazy? done some more digging here. The unfortunate thing is that our result object autocloses after any non-result returning operation, and as such it unconditionally retrieves the rowcount, typically a cheap/free operation, so that it is availble for those DBAPIs like kinterbasdb who require the cursor to be available. This means we can't make rowcount lazy. I can add an option to the kinterbasdb dialect to just turn off rowcount entirely, though. There seems to be ongoing debate about whether or not rowcount works at all with kinterbasdb. It seems to work perfectly over here, so it will just be up to the flag. Here's the CHANGES for that change: - The functionality of result.rowcount is now disabled by default, and can be re-enabled using the 'enable_rowcount' flag with create_engine(), as well as the 'enable_rowcount' execution context flag on a per-execute basis. This because cursor.rowcount requires cursor access (can't be evaluated lazily since the result auto-closes) and also incurs an expensive round-trip. so if you wanted to use the versioning feature with the ORM, you'd use an engine that has the flag turned on with that application. otherwise the ORM knows not to use rowcount. Thanks! -- 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. -- 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.
Re: [sqlalchemy] Is it normal that session.query(...).autoflush(False) still issues UPDATEs?
On Apr 11, 2010, at 4:28 PM, Peteris Krumins wrote: Hey everyone, Is it the expected behavior that after querying an object with `session.query(...).autoflush(False)...` and modifying some of its fields still makes it issue UPDATE when a relation of the object is referenced? Let me illustrate what I mean precisely. First I query the Page class: page = session.query(Page).autoflush(False).filter_by(page_id=...).first() Next, I assign a new title for the page: page.title = new title Now the page also has the `path` property that is a relation on Paths table. As soon as I do: print page.path I see that SQLAlchemy issues an UPDATE statement for the page.title, even though the page was said to be autoflush=False. I am wondering if this is the expected behavior? While the page should not autoflush, the relation still uses the session with autoflush=True. Somehow the relation's autoflush overtakes the Page query's autoflush and an UPDATE is issed... The behavior of page.path has no connection to the query(Page) previously emitted, and the autoflush() option on Query only refers to the flush() which would occur when that Query emits SQL. The Page object could just as well have already been present in the session when your query happened to return it - in which case it would be ambiguous which autoflush behavior it should be following. You can set autoflush to False on the Session directly and its advised that you use a context manager to make it convenient, as in http://www.sqlalchemy.org/trac/wiki/UsageRecipes/DisableAutoflush . -- 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.
Re: [sqlalchemy] Firebird and rowcount
Yesterday I downloaded 0.6beta3 and it took 27 seconds against 41 on 0.5. Pretty good results. 2010/4/10 Michael Bayer mike...@zzzcomputing.com: nekto0n wrote: Hi there! I'm now in the process of migrating from pure kinterbasdb to SQLAlchemy. Everything is fine except for speed of insertions and maybe updates. After some time of profiling I found out that a significant amount of time is spent on getting rowcount after execution. It takes about 5 seconds vs 41 spent on 3000 insertions themselves. That is 12%. Not much, but still. Digging further showed that rowcount attribute of kinterbasdb.Cursor is a getter, which remotely calles to Firebird Database. Here is the comment from _kicore_cursor.c source file: Determining rowcount is a fairly expensive operation that requires an isc_dsql_sql_info call. I wonder if there's any possible way to make getting rowcount optional or lazy? whats funny there is that the kinterbasdb is marked as not even supporting proper rowcount. the ORM shouldn't be calling it. Have you tried 0.6 ? Thanks! -- 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. -- 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. -- 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: Firebird and rowcount
Wow. That was fast =) Thanks for the fix. I'm a bit confused with results on 0.6beta3. Timer showed significant speed boost and profiler (and breakpoint in _CursorFairy) didn't show attempts to get rowcount. Am I doing something wrong? On Apr 12, 2:39 am, Michael Bayer mike...@zzzcomputing.com wrote: On Apr 9, 2010, at 4:51 PM, nekto0n wrote: Hi there! I'm now in the process of migrating from pure kinterbasdb to SQLAlchemy. Everything is fine except for speed of insertions and maybe updates. After some time of profiling I found out that a significant amount of time is spent on getting rowcount after execution. It takes about 5 seconds vs 41 spent on 3000 insertions themselves. That is 12%. Not much, but still. Digging further showed that rowcount attribute of kinterbasdb.Cursor is a getter, which remotely calles to Firebird Database. Here is the comment from _kicore_cursor.c source file: Determining rowcount is a fairly expensive operation that requires an isc_dsql_sql_info call. I wonder if there's any possible way to make getting rowcount optional or lazy? done some more digging here. The unfortunate thing is that our result object autocloses after any non-result returning operation, and as such it unconditionally retrieves the rowcount, typically a cheap/free operation, so that it is availble for those DBAPIs like kinterbasdb who require the cursor to be available. This means we can't make rowcount lazy. I can add an option to the kinterbasdb dialect to just turn off rowcount entirely, though. There seems to be ongoing debate about whether or not rowcount works at all with kinterbasdb. It seems to work perfectly over here, so it will just be up to the flag. Here's the CHANGES for that change: - The functionality of result.rowcount is now disabled by default, and can be re-enabled using the 'enable_rowcount' flag with create_engine(), as well as the 'enable_rowcount' execution context flag on a per-execute basis. This because cursor.rowcount requires cursor access (can't be evaluated lazily since the result auto-closes) and also incurs an expensive round-trip. so if you wanted to use the versioning feature with the ORM, you'd use an engine that has the flag turned on with that application. otherwise the ORM knows not to use rowcount. Thanks! -- 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 athttp://groups.google.com/group/sqlalchemy?hl=en. -- 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.
