[sqlalchemy] Re: Column name mapping problem in 0.3.7
Hi Rick, I still have rowcount issues on the latest svn. Also, is 'money' a native type? I'm currently setting ischema_names['money'] = MSNumeric Thanks, Graham On Jun 6, 6:34 pm, Rick Morrison [EMAIL PROTECTED] wrote: Hi Graham, There's a good chance that only you and I are using pymssql, and I don't have have the long identifiers problem, so it kind of dropped throught the cracks, sorry. I've checked in the 30-character thing, but I've left off the sane_rowcount for now. I had run into issues with that back in March, and I ended up patching pymssql to fix the problem rather than set sane_rowcount to False. Can't remember why now, I'm currently running our local test suite which should remind me. Rick On 6/6/07, Graham Stratton [EMAIL PROTECTED] wrote: I'm bringing this old thread up because I'm still having the same issue with 0.3.8. In order to use mssql I have to add def max_identifier_length(self): return 30 to the pymssql dialect. I also find that I need to set has_sane_rowcount=False (as I have had to with every release). Is anyone else using pymssql? Do you have the same problems? Should these changes be made on the trunk? Thanks, Graham On May 1, 7:13 pm, Michael Bayer [EMAIL PROTECTED] wrote: it is max_identifier_length() on Dialect. ive also gone and figured out why it is hard to separate the max length of columns vs. that of labels...its because of some issues that arise with some auto-labeling that happens inside of ansisql.pyso its fortunate i dont have to get into that. On May 1, 2007, at 12:57 PM, Rick Morrison wrote: The underlying DBlib limits *all* identifier names, including column names to 30 chars anyway, so no issue there. Where does the character limit go in the dialect? Can I follow Oracle as an example? On 5/1/07, Michael Bayer [EMAIL PROTECTED] wrote: On May 1, 2007, at 11:18 AM, Rick Morrison wrote: The label-truncation code is fine. The issue isn't SA. It's the DBAPI that pymssql rides on top of...identifier limit is 30 chars, is deprecated by Microsoft, it will never be fixed. Try pyodbc, which has no such limitation. OK well, we should put the 30-char limit into pymssql's dialect. however, the way the truncation works right now, its going to chop off all the column names too...which means unless i fix that, pymssql cant be used with any columns over 30 chars in size. --~--~-~--~~~---~--~~ 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: Column name mapping problem in 0.3.7
I'm bringing this old thread up because I'm still having the same issue with 0.3.8. In order to use mssql I have to add def max_identifier_length(self): return 30 to the pymssql dialect. I also find that I need to set has_sane_rowcount=False (as I have had to with every release). Is anyone else using pymssql? Do you have the same problems? Should these changes be made on the trunk? Thanks, Graham On May 1, 7:13 pm, Michael Bayer [EMAIL PROTECTED] wrote: it is max_identifier_length() on Dialect. ive also gone and figured out why it is hard to separate the max length of columns vs. that of labels...its because of some issues that arise with some auto-labeling that happens inside of ansisql.pyso its fortunate i dont have to get into that. On May 1, 2007, at 12:57 PM, Rick Morrison wrote: The underlying DBlib limits *all* identifier names, including column names to 30 chars anyway, so no issue there. Where does the character limit go in the dialect? Can I follow Oracle as an example? On 5/1/07, Michael Bayer [EMAIL PROTECTED] wrote: On May 1, 2007, at 11:18 AM, Rick Morrison wrote: The label-truncation code is fine. The issue isn't SA. It's the DBAPI that pymssql rides on top of...identifier limit is 30 chars, is deprecated by Microsoft, it will never be fixed. Try pyodbc, which has no such limitation. OK well, we should put the 30-char limit into pymssql's dialect. however, the way the truncation works right now, its going to chop off all the column names too...which means unless i fix that, pymssql cant be used with any columns over 30 chars in size. --~--~-~--~~~---~--~~ 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] Precompiling O/RM queries?
Hi, I'm getting some surprisingly poor performance from SQLAlchemy in .get() operations. They're typically taking about 100-200ms, though varying quite a lot. Just doing engine.execute() on the echo()ed SQL takes about 10ms. The query is not small, with a few LEFT OUTER JOINS to eagerly loaded attributes, but it's not massive. As far as I can work out, the query generation is responsible for most of the extra time. Assuming that it's expected that the query generation is quite slow, is it possible to cache the generated queries? I see that you can do so with select objects, but is there a way to do so with O/RM queries? Thanks, Graham --~--~-~--~~~---~--~~ 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: Precompiling O/RM queries?
do you mean, the compilation of the Select object into a string ? extremely unlikely. the main speed issue with get() is that of fetching rows from DBAPI and processing into object results, which goes up by a huge margin if you have a lot of eagerly loaded instances attached to the get. the ORM has to create a copy of each object's attributes in memory in order to track attribute history as well as perform a lot of other bookkeeping. what youre looking for is a second-level cache which is currently a RYO (roll-your-own) feature. I ran a few get()s with non-existent ids (which are therefore returning no rows, confirmed by setting engine.echo to 'debug'). The average query time was about 80ms, though it varied from 56ms to 110ms. I also called engine.execute with the generated SQL a few times, substituting in different ids. The query time was quite consistently around 17ms. The variation in the time to do get()s seems particularly strange. Thanks, Graham --~--~-~--~~~---~--~~ 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] Ticket 185-like issues on inheriting from alias in 0.3.7
Hi, Now I've set the maximum identifier length to 30 chars (thanks!), I have a new problem. My Person class inherits from PersonEntry, and the get() method on Person now fails when passed a single id. This seems to be due to the removal of the workaround for #185 in orm.query.Query._get I have another example where inheritance works fine. It seems to fail in this instance because the table that PersonEntry is mapped to is an alias. Should it be possible to set up inheritance from an aliased table? It worked in 0.3.6, and the inheritance still works apart from get() in 0.3.7. Thanks, Graham Person.get([449142, 449142]) John Smith Person.get_by(id=449142) John Smith Person.get(449142) Traceback (most recent call last): File stdin, line 1, in ? File /usr/local/lib/python2.4/site-packages/SQLAlchemy-0.3.7- py2.4.egg/sqlalchemy/ext/assignmapper.py, line 7, in do return getattr(query, name)(*args, **kwargs) File /usr/local/lib/python2.4/site-packages/SQLAlchemy-0.3.7- py2.4.egg/sqlalchemy/orm/query.py, line 103, in get return self._get(key, ident, **kwargs) File /usr/local/lib/python2.4/site-packages/SQLAlchemy-0.3.7- py2.4.egg/sqlalchemy/orm/query.py, line 916, in _get params[primary_key._label] = ident[i] IndexError: list index out of range --~--~-~--~~~---~--~~ 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] Column name mapping problem in 0.3.7
Hi, I've just upgraded to 0.3.7, and when the combined table/column name is at least 30 characters I get an error from the mapper like this: sqlalchemy.exceptions.NoSuchColumnError: Could not locate column in row for column 'Column(u'EventLastCancellationDate',MSDate())' Is this a problem with the changes in 0.3.7 ? I'm using pymssql 0.8.0 with SQL server 2000. Thanks, Graham --~--~-~--~~~---~--~~ 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: Column name mapping problem in 0.3.7
To add a little more info, 0.3.6 generates: SELECT [T_Event].[EventLastCancellationDate] AS [T_Event_EventLastCancell_8ab9] whereas 0.3.7 generates [T_Event].[EventLastCancellationDate] AS [T_Event_EventLastCancellationDate] From what I can find, column names can be up to 128 chars in SQL server, but maybe pymssql is truncating at 30? Graham On May 1, 8:45 am, Graham Stratton [EMAIL PROTECTED] wrote: Hi, I've just upgraded to 0.3.7, and when the combined table/column name is at least 30 characters I get an error from the mapper like this: sqlalchemy.exceptions.NoSuchColumnError: Could not locate column in row for column 'Column(u'EventLastCancellationDate',MSDate())' Is this a problem with the changes in 0.3.7 ? I'm using pymssql 0.8.0 with SQL server 2000. Thanks, Graham --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
