Hi Michael:

Looking for a bit of direction here.

In the early stages of implementation of MS-SQL. There are a few things that are going to force some changes in the current implementation. Let me start with a simple one first, the ANSI LIMIT clause vs. the MS-SQL TOP. As you know the ANSI clause comes at the end of an SQL statement:

  SELECT x FROM y ORDER BY x LIMIT 10

MS-SQL puts it here:

  SELECT TOP 10 x FROM y ORDER BY x

There's a few ways to go here. Here's a few options, and my opinions of each:


a) Make any ANSI-nonconforming database engine provide it's own visit_select().
      --- This is the most natural way, but the visit_select() method is the longest and most complex of all of the SQL compiler methods. Taking this road would mean that any future changes to visit_select() would probably not be inherited by the database engines, and be a bit of a maintenance headache.

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:

 def descriptor():
    return {'name':'mssql',
    'description':'MS SQL Server',
    'arguments':[
        ('user',"Database Username",None),
                     ....
         ],
    'features': {
    'limit':2,   # Post SELECT position (i.e. SELECT TOP xx [cols])
        'offset':0,  # Not supported
        }
     }


   and then the default visit_select() could use the "features" data to construct the appropriate query.

      -- This is kind of ugly, but would be rather easy to do.


c) refactor the visit_select() into a set of smaller methods that could handle differences like this.
     -- This is most likely the OOD/OOP "proper" way to do things, but it's going to be hard to refactor so that the SELECT clause building process is still comprehensible by us humans. It's not a job I would want.


I would vote for option (b) -- What do you think?


Rick

Reply via email to