You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello! I''ve written an sql transpiler (from scratch, in rust), it's around 25K lines of code and it isn't perfect nor fully completed nor it has dialects support, but it works. I did it to build an sql linter/formatter for my work, but they decided not to use it :D. I think it has potential and I think the dbt core can take advantage of it. It doesn't support jinja templating, and I am not sure it will be straightforward to add support for it in case you want to process the jinja templating at the same time, but there should be workarounds. It also has a binding resolution stage, so you could potentially query the schema from the database or from the dbt models and it could check that your sql is valid. Another big advantage that I was working on (but didn't build) is to translate old databases to the dbt structure. It also can run fully on the web by using wasm. With all that said, my question is; do you guys want your own sql parser? To be honest my sql parser it's quite a lot, and most of the parts, although they are very readable, lack documentation. I know there are other good sql parsers, so I am not sure what (if any) is stopping dbt to have its own parser. But if you guys want your own parser you can probably leverage mine as I don't think my company will use it.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hello! I''ve written an sql transpiler (from scratch, in rust), it's around 25K lines of code and it isn't perfect nor fully completed nor it has dialects support, but it works. I did it to build an sql linter/formatter for my work, but they decided not to use it :D. I think it has potential and I think the dbt core can take advantage of it. It doesn't support jinja templating, and I am not sure it will be straightforward to add support for it in case you want to process the jinja templating at the same time, but there should be workarounds. It also has a binding resolution stage, so you could potentially query the schema from the database or from the dbt models and it could check that your sql is valid. Another big advantage that I was working on (but didn't build) is to translate old databases to the dbt structure. It also can run fully on the web by using wasm. With all that said, my question is; do you guys want your own sql parser? To be honest my sql parser it's quite a lot, and most of the parts, although they are very readable, lack documentation. I know there are other good sql parsers, so I am not sure what (if any) is stopping dbt to have its own parser. But if you guys want your own parser you can probably leverage mine as I don't think my company will use it.
Beta Was this translation helpful? Give feedback.
All reactions