The ORM expects a return value from a statement execution - when it emits INSERT, it assumes the INSERT has taken place. It needs to see the value of newly inserted primary key identifiers, which come from cursor.lastrowid, RETURNING, or similar. When UPDATE or DELETE, it needs to know how many rows were matched. How exactly would this still-very-vaguely-described library choose to augment the ORM's behavior in such a fundamental way, without modifying the ORM itself ? How can the ORM do its job if its given a connection handle that acts in an effectively broken way ? Would an end-user's call to add() + commit() still result in an INSERT of the data ? or if not, how is that useful ?
If you're building some kind of transparent sharding system that for some reason needs to have some statements effectively do nothing, or something that doesn't at all resemble what the user is requesting (not really sure what that would accomplish), this seems like you'd want to wrap the DBAPI connection itself and modify its behavior at the cursor level, so that from an outsider's perspective, it sees a DBAPI connection, a cursor, and the expected state when an INSERT, UPDATE or DELETE occurs - with whatever magic you're building ensuring that a reasonable state remains on the cursor and connection. SQLAlchemy, and especially the ORM, unfortunately requires that the DBAPI connection and cursor acts like such - when a statement is emitted, it expects a sensible result, or an exception. "None" is not an option. Such sharding/replication systems are extremely difficult to build. For this reason such transparent systems are usually implemented either on the database backend itself using replication, specialized database proxies, or are implemented in the application scope - such as using different Session objects for the "master" and "slave" databases, for example. On May 3, 2011, at 1:02 PM, bool wrote: > No. My use case should work irrespective of whether user chooses to > use SQL Expression or ORM. So a simple function that receives a > statement and does what is needed will not work for me. > > -- > 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. > -- 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.
