Re: [sqlalchemy] Re: SQLAlchemy Sessions
On Sun, Mar 28, 2010 at 10:19 AM, Peteris Krumins peteris.krum...@gmail.com wrote: This is the best explanation I have read on this topic! Thanks for writing it! Now I clearly see what is going on. Just one more thing - when should remove() be called? (if at all) The model that works for me is as follows: 1) use scoped_session() which will give every function in your Web app the same session when they call session = Session() locally. 2) If you have a long-running process that handles more than one HTTP request, only close() or remove() the session once, at the end of the HTTP request (generally, it's a good idea to add this to a finish() method for the HTTP request handler or something so it is done automatically.) This will ensure that each request gets a new, fresh session. Regards, Daniel -- 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] Restricting a delete based on a many-to-many mapping.
How is the best way to restrict a delete on an item if it has a value in a many-to-many mapping? For example: I have three tables: User, Group, and UserGroup. UserGroup is a many- to-many mapping table between User and Group. User has a relation called 'groups' and Group has a relation called 'users'. Pretty simple schema. I want the ability to delete a group, but only if it is not used by a user in which case I want it to fail. If I do 'session.delete(group)' it removes all the items in UserGroup so that it will always succeed. One obvious solution is to always check the length of the 'users' attribute whenever I want to remove a group. Is there a more generic way to do this that I can specify at the mapper level? -- 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] PyODBCConnector dbapi question
Hello,
I had a custom dialect based on the PyODBC functionality that was
working with SQLA SVN-6738. Upgrading to beta 3, my tests no longer
pass, so I've begun the process updating - on_connect() was easy, now
I'm stumped on connect(...). I've gotten to the point where, when
using my dialect, connect() fails because it attempts to run
self.dbapi.connect(...) but the PyODBC connector seems to implement it
as a classmethod:
Taking the following from the connector in revision control:
9 class PyODBCConnector(Connector):
27 @classmethod
28 def dbapi(cls):
29 return __import__('pyodbc')
84 def initialize(self, connection):
85 # determine FreeTDS first. can't issue SQL easily
86 # without getting unicode_statements/binds set up.
87
88 pyodbc = self.dbapi
89
90 dbapi_con = connection.connection
91
92 self.freetds = bool(re.match(r.*libtdsodbc.*\.so,
dbapi_con.getinfo(pyodbc.SQL_DRIVER_NAME)))
If dbapi is implemented as a class method, then wouldn't the call on
line 92 fail? Indeed, that's what I'm seeing. So is self.dbapi
getting assigned somewhere else?
Thanks,
Bo
--
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] PyODBCConnector dbapi question
Bo Shi wrote:
Hello,
I had a custom dialect based on the PyODBC functionality that was
working with SQLA SVN-6738. Upgrading to beta 3, my tests no longer
pass, so I've begun the process updating - on_connect() was easy, now
I'm stumped on connect(...). I've gotten to the point where, when
using my dialect, connect() fails because it attempts to run
self.dbapi.connect(...) but the PyODBC connector seems to implement it
as a classmethod:
Taking the following from the connector in revision control:
9 class PyODBCConnector(Connector):
27@classmethod
28def dbapi(cls):
29return __import__('pyodbc')
84def initialize(self, connection):
85# determine FreeTDS first. can't issue SQL easily
86# without getting unicode_statements/binds set up.
87
88pyodbc = self.dbapi
89
90dbapi_con = connection.connection
91
92self.freetds = bool(re.match(r.*libtdsodbc.*\.so,
dbapi_con.getinfo(pyodbc.SQL_DRIVER_NAME)))
If dbapi is implemented as a class method, then wouldn't the call on
line 92 fail? Indeed, that's what I'm seeing. So is self.dbapi
getting assigned somewhere else?
yeah there's a slight misfortune in that naming scheme - the @classmethod
should have some different name, probably import_dbapi. the
reassignment takes place on line 102 of sqlalchemy/engine/default.py.
this naming scheme is also present in 0.5 - it was just the
PyODBCConnector that somehow didn't catch up until recently.
Thanks,
Bo
--
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] PyODBCConnector dbapi question
Thanks, explicitly assigning self.dbapi in my dialect constructor
seems to get around the exception.
I do, however, encounter a new exception:
File test_vertica.py, line 57, in testTransactionIsolation
_, iso_level = e.execute('SHOW TRANSACTION_ISOLATION').fetchone()
File
/home/vmc/ENV/lib/python2.6/site-packages/SQLAlchemy-0.6beta2-py2.6-linux-x86_64.egg/sqlalchemy/engine/base.py,
line 2204, in fetchone
return self.process_rows([row])[0]
File
/home/vmc/ENV/lib/python2.6/site-packages/SQLAlchemy-0.6beta2-py2.6-linux-x86_64.egg/sqlalchemy/engine/base.py,
line 2163, in process_rows
for row in rows]
TypeError: row must be a tuple
Any idea what's going on? The stack trace isn't very informative, I'm afraid.
On Mon, Mar 29, 2010 at 6:05 PM, Michael Bayer mike...@zzzcomputing.com wrote:
Bo Shi wrote:
Hello,
I had a custom dialect based on the PyODBC functionality that was
working with SQLA SVN-6738. Upgrading to beta 3, my tests no longer
pass, so I've begun the process updating - on_connect() was easy, now
I'm stumped on connect(...). I've gotten to the point where, when
using my dialect, connect() fails because it attempts to run
self.dbapi.connect(...) but the PyODBC connector seems to implement it
as a classmethod:
Taking the following from the connector in revision control:
9 class PyODBCConnector(Connector):
27 �...@classmethod
28 def dbapi(cls):
29 return __import__('pyodbc')
84 def initialize(self, connection):
85 # determine FreeTDS first. can't issue SQL easily
86 # without getting unicode_statements/binds set up.
87
88 pyodbc = self.dbapi
89
90 dbapi_con = connection.connection
91
92 self.freetds = bool(re.match(r.*libtdsodbc.*\.so,
dbapi_con.getinfo(pyodbc.SQL_DRIVER_NAME)))
If dbapi is implemented as a class method, then wouldn't the call on
line 92 fail? Indeed, that's what I'm seeing. So is self.dbapi
getting assigned somewhere else?
yeah there's a slight misfortune in that naming scheme - the @classmethod
should have some different name, probably import_dbapi. the
reassignment takes place on line 102 of sqlalchemy/engine/default.py.
this naming scheme is also present in 0.5 - it was just the
PyODBCConnector that somehow didn't catch up until recently.
Thanks,
Bo
--
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.
--
Bo Shi
617-942-1744
--
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] PyODBCConnector dbapi question
Also, dunno if it's helpful or not, but this is a regression in
0.6beta3. My dialect plugin works as is when using 0.6beta2.
On Mon, Mar 29, 2010 at 7:41 PM, Bo Shi bs1...@gmail.com wrote:
Thanks, explicitly assigning self.dbapi in my dialect constructor
seems to get around the exception.
I do, however, encounter a new exception:
File test_vertica.py, line 57, in testTransactionIsolation
_, iso_level = e.execute('SHOW TRANSACTION_ISOLATION').fetchone()
File
/home/vmc/ENV/lib/python2.6/site-packages/SQLAlchemy-0.6beta2-py2.6-linux-x86_64.egg/sqlalchemy/engine/base.py,
line 2204, in fetchone
return self.process_rows([row])[0]
File
/home/vmc/ENV/lib/python2.6/site-packages/SQLAlchemy-0.6beta2-py2.6-linux-x86_64.egg/sqlalchemy/engine/base.py,
line 2163, in process_rows
for row in rows]
TypeError: row must be a tuple
Any idea what's going on? The stack trace isn't very informative, I'm afraid.
On Mon, Mar 29, 2010 at 6:05 PM, Michael Bayer mike...@zzzcomputing.com
wrote:
Bo Shi wrote:
Hello,
I had a custom dialect based on the PyODBC functionality that was
working with SQLA SVN-6738. Upgrading to beta 3, my tests no longer
pass, so I've begun the process updating - on_connect() was easy, now
I'm stumped on connect(...). I've gotten to the point where, when
using my dialect, connect() fails because it attempts to run
self.dbapi.connect(...) but the PyODBC connector seems to implement it
as a classmethod:
Taking the following from the connector in revision control:
9 class PyODBCConnector(Connector):
27 �...@classmethod
28 def dbapi(cls):
29 return __import__('pyodbc')
84 def initialize(self, connection):
85 # determine FreeTDS first. can't issue SQL easily
86 # without getting unicode_statements/binds set up.
87
88 pyodbc = self.dbapi
89
90 dbapi_con = connection.connection
91
92 self.freetds = bool(re.match(r.*libtdsodbc.*\.so,
dbapi_con.getinfo(pyodbc.SQL_DRIVER_NAME)))
If dbapi is implemented as a class method, then wouldn't the call on
line 92 fail? Indeed, that's what I'm seeing. So is self.dbapi
getting assigned somewhere else?
yeah there's a slight misfortune in that naming scheme - the @classmethod
should have some different name, probably import_dbapi. the
reassignment takes place on line 102 of sqlalchemy/engine/default.py.
this naming scheme is also present in 0.5 - it was just the
PyODBCConnector that somehow didn't catch up until recently.
Thanks,
Bo
--
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.
--
Bo Shi
617-942-1744
--
Bo Shi
617-942-1744
--
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] PyODBCConnector dbapi question
how come the strack trace shows beta2 as the version number in the path ?
did you mean to say between beta1 and beta2 ? it looks specific to the C
rewrite of RowProxy. basically the rows returned by fetchone(), fetchall()
etc. are expected to be tuples. pep 249 specifies list of tuples for
fetchmany() and fetchall() though is less specific for fetchone(), though I'm
pretty sure it intends tuples there as well.
On Mar 29, 2010, at 7:43 PM, Bo Shi wrote:
Also, dunno if it's helpful or not, but this is a regression in
0.6beta3. My dialect plugin works as is when using 0.6beta2.
On Mon, Mar 29, 2010 at 7:41 PM, Bo Shi bs1...@gmail.com wrote:
Thanks, explicitly assigning self.dbapi in my dialect constructor
seems to get around the exception.
I do, however, encounter a new exception:
File test_vertica.py, line 57, in testTransactionIsolation
_, iso_level = e.execute('SHOW TRANSACTION_ISOLATION').fetchone()
File
/home/vmc/ENV/lib/python2.6/site-packages/SQLAlchemy-0.6beta2-py2.6-linux-x86_64.egg/sqlalchemy/engine/base.py,
line 2204, in fetchone
return self.process_rows([row])[0]
File
/home/vmc/ENV/lib/python2.6/site-packages/SQLAlchemy-0.6beta2-py2.6-linux-x86_64.egg/sqlalchemy/engine/base.py,
line 2163, in process_rows
for row in rows]
TypeError: row must be a tuple
Any idea what's going on? The stack trace isn't very informative, I'm
afraid.
On Mon, Mar 29, 2010 at 6:05 PM, Michael Bayer mike...@zzzcomputing.com
wrote:
Bo Shi wrote:
Hello,
I had a custom dialect based on the PyODBC functionality that was
working with SQLA SVN-6738. Upgrading to beta 3, my tests no longer
pass, so I've begun the process updating - on_connect() was easy, now
I'm stumped on connect(...). I've gotten to the point where, when
using my dialect, connect() fails because it attempts to run
self.dbapi.connect(...) but the PyODBC connector seems to implement it
as a classmethod:
Taking the following from the connector in revision control:
9 class PyODBCConnector(Connector):
27@classmethod
28def dbapi(cls):
29return __import__('pyodbc')
84def initialize(self, connection):
85# determine FreeTDS first. can't issue SQL easily
86# without getting unicode_statements/binds set up.
87
88pyodbc = self.dbapi
89
90dbapi_con = connection.connection
91
92self.freetds = bool(re.match(r.*libtdsodbc.*\.so,
dbapi_con.getinfo(pyodbc.SQL_DRIVER_NAME)))
If dbapi is implemented as a class method, then wouldn't the call on
line 92 fail? Indeed, that's what I'm seeing. So is self.dbapi
getting assigned somewhere else?
yeah there's a slight misfortune in that naming scheme - the @classmethod
should have some different name, probably import_dbapi. the
reassignment takes place on line 102 of sqlalchemy/engine/default.py.
this naming scheme is also present in 0.5 - it was just the
PyODBCConnector that somehow didn't catch up until recently.
Thanks,
Bo
--
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.
--
Bo Shi
617-942-1744
--
Bo Shi
617-942-1744
--
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] PyODBCConnector dbapi question
how come the strack trace shows beta2 as the version number in the path ?
Yeesh. My bad; I spoke too soon.
As you had hypothesized, the error occurs only when I install using
--with-cextensions (it doesn't have anything to do with beta2/3).
Thanks,
Bo
On Mon, Mar 29, 2010 at 8:03 PM, Michael Bayer mike...@zzzcomputing.com wrote:
how come the strack trace shows beta2 as the version number in the path ?
did you mean to say between beta1 and beta2 ? it looks specific to the C
rewrite of RowProxy. basically the rows returned by fetchone(), fetchall()
etc. are expected to be tuples. pep 249 specifies list of tuples for
fetchmany() and fetchall() though is less specific for fetchone(), though I'm
pretty sure it intends tuples there as well.
On Mar 29, 2010, at 7:43 PM, Bo Shi wrote:
Also, dunno if it's helpful or not, but this is a regression in
0.6beta3. My dialect plugin works as is when using 0.6beta2.
On Mon, Mar 29, 2010 at 7:41 PM, Bo Shi bs1...@gmail.com wrote:
Thanks, explicitly assigning self.dbapi in my dialect constructor
seems to get around the exception.
I do, however, encounter a new exception:
File test_vertica.py, line 57, in testTransactionIsolation
_, iso_level = e.execute('SHOW TRANSACTION_ISOLATION').fetchone()
File
/home/vmc/ENV/lib/python2.6/site-packages/SQLAlchemy-0.6beta2-py2.6-linux-x86_64.egg/sqlalchemy/engine/base.py,
line 2204, in fetchone
return self.process_rows([row])[0]
File
/home/vmc/ENV/lib/python2.6/site-packages/SQLAlchemy-0.6beta2-py2.6-linux-x86_64.egg/sqlalchemy/engine/base.py,
line 2163, in process_rows
for row in rows]
TypeError: row must be a tuple
Any idea what's going on? The stack trace isn't very informative, I'm
afraid.
On Mon, Mar 29, 2010 at 6:05 PM, Michael Bayer mike...@zzzcomputing.com
wrote:
Bo Shi wrote:
Hello,
I had a custom dialect based on the PyODBC functionality that was
working with SQLA SVN-6738. Upgrading to beta 3, my tests no longer
pass, so I've begun the process updating - on_connect() was easy, now
I'm stumped on connect(...). I've gotten to the point where, when
using my dialect, connect() fails because it attempts to run
self.dbapi.connect(...) but the PyODBC connector seems to implement it
as a classmethod:
Taking the following from the connector in revision control:
9 class PyODBCConnector(Connector):
27 �...@classmethod
28 def dbapi(cls):
29 return __import__('pyodbc')
84 def initialize(self, connection):
85 # determine FreeTDS first. can't issue SQL easily
86 # without getting unicode_statements/binds set up.
87
88 pyodbc = self.dbapi
89
90 dbapi_con = connection.connection
91
92 self.freetds = bool(re.match(r.*libtdsodbc.*\.so,
dbapi_con.getinfo(pyodbc.SQL_DRIVER_NAME)))
If dbapi is implemented as a class method, then wouldn't the call on
line 92 fail? Indeed, that's what I'm seeing. So is self.dbapi
getting assigned somewhere else?
yeah there's a slight misfortune in that naming scheme - the @classmethod
should have some different name, probably import_dbapi. the
reassignment takes place on line 102 of sqlalchemy/engine/default.py.
this naming scheme is also present in 0.5 - it was just the
PyODBCConnector that somehow didn't catch up until recently.
Thanks,
Bo
--
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.
--
Bo Shi
617-942-1744
--
Bo Shi
617-942-1744
--
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.
--
Bo Shi
617-942-1744
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
Re: [sqlalchemy] Restricting a delete based on a many-to-many mapping.
On Mar 29, 2010, at 4:20 PM, Rich wrote: How is the best way to restrict a delete on an item if it has a value in a many-to-many mapping? For example: I have three tables: User, Group, and UserGroup. UserGroup is a many- to-many mapping table between User and Group. User has a relation called 'groups' and Group has a relation called 'users'. Pretty simple schema. I want the ability to delete a group, but only if it is not used by a user in which case I want it to fail. If I do 'session.delete(group)' it removes all the items in UserGroup so that it will always succeed. One obvious solution is to always check the length of the 'users' attribute whenever I want to remove a group. Is there a more generic way to do this that I can specify at the mapper level? you want the delete to fail if there *are* users associated or if there are *not* ?for the raise an error if users exist, the most efficient and generic way is to ensure the foreign key on UserGroup is not nullable and delete cascade isn't used.if you wanted to dig an assertion into the mapper you could use a before_delete() extension. -- 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.
