6 ms·

You've completely missed the point. Author's talking about parsing SQL. That's utterly different from using infoschema to get an existing table structure.

• trollied 4y ago
  No, I have not. The article has no clear direction, hence your comment. The article talks about parsing SQL DDL with the goal of creating classes/structures that represent the tables. You do not need to parse SQL to achieve this. The premise at the start of the article is "parsing SQL so that we can achieve things in code that is not possible in SQL". If that were indeed the case, there would be no such SQL to parse in the first place!
  • zasdffaa 4y ago
    > creating classes/structures that represent the tables AFAICS he's talking about creating AST objects. If the tables don't exist, you can't query the infoschema because the tables don't exist. Someone has to parse the table-definition source code to work out what the tables must eventually look like when turned into structures in the database.
  • chrisjc 4y ago
    Perhaps I missed the point too, but the way I understand the post is that it's demonstrating how to parse DDLs so that a model (AST) of the actions and structures can be extracted. From there an implementation can be defined to create, alter, drop, etc the respective objects and then probably update some kind of manifest that represents the objects and potentially its relationship to others. In most databases that manifest is the INFORMATION_SCHEMA.