Re: [Sqlalchemy-users] LIMIT vs TOP

[Michael Bayer]

a) Make any ANSI-nonconforming database engine provide it's own visit_select(). b) Beef up the dbengine desciptor() data, and add some if/then logic to the base visit_select() to handle the various scenarios. For example, the descriptor data for the MSSQL engine could look like: ... c) refactor the visit_select() into a set of smaller methods that could handle differences like this. option "b" is the *last* route I would go with.  the reason for the whole "visit" idea is so that generation of SQL is decoupled from the schema structure itself.  similarly, the whole reason for the individual database modules is to decouple database-specific SQL concepts from those that are globally supported within ANSI SQL.  not that there arent hacks here and there but those are the rare exceptions; polymorphism is the rule. option "c" has actually been in progress to some extent, if you look at old versions of visit_select() youll see it was a lot more monolithic than it is now.  this option is not as bad as it seems.  while youll have to show me how the OFFSET side of the equation figures into MS-SQL, it seems easy enough to provide a no-op "get_select_modifiers()" method to ANSICompiler and the "TOP" version to MSSQLCompiler and just call it right after line 279 of ansisql.py where it enters "SELECT" into the string.    for more serious syntactical issues, the way I have been going them for now, particularly with Oracle, is option "d" - override visit_select() to make modifications to the incoming Select object before relying upon the underlying visit_select() to do most of the work.   the only drawback to this method is that the Select object needs a reliable "copy" method so that it can leave the original Select untouched, there is a trac ticket to make that happen.