Re: [sqlalchemy] Querying mssql time columns
Thanks Michael, you're correct I'm using pyodbc with FreeTDS, which doesn't recognize the time datatype (and it seems FreeTDS doesn't support anything above SQLServer 2005). And you're right, this is not a SQLAlchemy issue. Sorry about that. I guess I can work around this by using time.isoformat() in filter constraints. Hope that's portable to windows! Thanks (again) for your help--this is the second time you've helped me out here. Much appreciated. Simon. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To view this discussion on the web visit https://groups.google.com/d/msg/sqlalchemy/-/pyeq1WoO18IJ. 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] Querying mssql time columns
I think I've found a bug--can anyone else confirm this? It appears that SQLAlchemy cannot query SQLServer time columns because Python datetime.time objects are always promoted to full datetime types. Once promoted the SQLServer returns the error: 'The data types time and datetime are incompatible in the greater than operator. (402) (SQLExecDirectW)'. The type promotion occurs in sqlalchemy/dialects/mssql/base.py:268-276. Interestingly, according to the documentation in this file, SQLAlchemy can already determine whether the DATE and TIME types are supported (in SQLServer 2008 or later), and I have confirmed it emits the correct DDL but still treats all bound time values as DATETIMEs anyway. Is this a bug or am I missing something? Many thanks, Simon. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To view this discussion on the web visit https://groups.google.com/d/msg/sqlalchemy/-/_30ui_LT8qcJ. 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.
Re: [sqlalchemy] Have I found a bug with MSSQL/PyODBC identity maps?
Thanks Michael, On Friday, October 7, 2011 12:44:16 AM UTC+11, Michael Bayer wrote: There are two things that come to mind that could specifically cause this behavior. One is, the identifier of 1 as an integer does not actually match the datatype received back from the MSSQL database - such as if the database returned a string 1, that would cause the get() above to not locate integer 1 in the cache. This was exactly the issue. Many thanks for your help with this--apologies for not getting back to you sooner. Simon. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To view this discussion on the web visit https://groups.google.com/d/msg/sqlalchemy/-/wHBak5H-MVAJ. 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] Have I found a bug with MSSQL/PyODBC identity maps?
I'm fairly new to SQLAlchemy so I want to double-check this before filing
what I think is a bug against SQLAlchemy 0.7.
Consider a plain, declarative-mapped object:
class Table(Base):
__tablename__ = 'table'
id = Column(Integer, primary_key=True, nullable=False)
Now consider code to retrieve this item:
function test_identity_map():
db=Session() # scoped_session(sessionmaker(...))
for x in range(5):
print %d: %s % (x, db.query(Table).get(1))
If I create a MSSQL engine with a connection string prefix of
'mssql+pyodbc://', set 'echo' to True, populate the table with a single item
with an id of '1' and call the test function, five separate SQL statements
are echoed to the console. However, if I repeat the process using the SQLite
in-memory engine ('sqlite:///:memory:'), only one SQL statement is echoed to
the console.
I believe the mssql/pyodbc engine is not caching the item in the identity
map. Could it be that the behaviour of 'echo=True' when supplied to
create_engine differs between engine types, such that SQL is always echoed
for the mssql engine, and the item is retrieved from the identity map anyway
(I haven't checked whether the calls are actually emitted to the database,
but the timing information leads me to believe they are)? Or could there be
some other configuration setting I've overlooked? Could it be that I'm using
FreeTDS on linux for the ODBC layer? Stores/retrievals otherwise work just
fine. I've looked through the dialect code and can't find anything that
might affect this. Am I missing something? I'm going to dig into the session
identity map code now to see what I can find, but I'd appreciate it if
anyone already knows where I'm going wrong.
Many thanks,
Simon.
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To view this discussion on the web visit
https://groups.google.com/d/msg/sqlalchemy/-/lPYhk2PpHgAJ.
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.
