Validating SQLalchemy

I have used SQLalchemy for a few projects and one of the things that annoys me, not so much from the structure, but the effects of code inside strings. All code is text which is parsed, however, we have inside IDE’s and for me inside VIM the ability to see the syntax errors as we are coding. No such thing exists for the code inside the strings which specify the joins of the relations in SQLalchemy.

For this project, there are some core things the program needs to be able to do.

• Discover the file which contains the table object mappings
• Look for relation strings in those objects
• Validate the syntax of those strings
• Check that tables/columns referenced are valid
• Maybe enforce a syntax styling rule

The file discovery shouldn’t be too taxing; most SQLAlchemy projects have a single folder in which the table objects are stored and each table needs to inherit from an sqlalchemy declarative base object.

I thought that this project would be a good opportunity to learn elements of Python’s AST module which allows for the dealing with abstract syntax trees.

Using AST I can parse the strings which are the declared joins for the SQLAlchemy objects.

I really like the idea of getting an intuitive understanding and a proficiency with AST because it would make it easier to code on another level. Like how text search is to regex, I think using AST could be to writing code.

One of the day to day coding elements it would allow for is the automatic propagation of information through a pure call stack. That would keep the functions pure and therefore easier to understand and test while not taking a long time to work out where the information should come from and how it should be passed down.

You might argue that this would lead to functions with a large number of calling arguments, and alone the previous suggestions would, but with AST a few lines in the repl loop or a function that ran in the background and you would have suggestions of creating objects where common arguments are passed together. The developer can then see where useful abstractions might be drawn and improve the readability of the whole codebase.

No global variables needed, nor their modern counterpart, class-level variables used as globals.

Certainly a project to add to the pile.