This is actually something I thought of doing, but you actually did it. It would be amazing if you can find a way to open-source at least part of it.
But my application was to be able to use raw SQL queries instead of an ORM in an application. By statically analyzing the SQL queries, then you can, in a statically typed language, automatically type-check the parameters to and results of the queries.
Combining that and an IDE like the Jetbrains ones, which provide intelligent SQL autocompletion/refactoring, then tbh., I think it would beat an ORM in terms of ergonomics. Some people like LINQ or various Haskell/Scala ORMs because they are type-safe. This would be totally natural to those who know SQL without the downsides of being totally unanalyzed and type-checked.
It would be like the clojure library called hugs, but with static type-checking.
Look at this, I've returned the ability to export types :)
In beta now available renderers for flow and ts.
You can see alive how the export results change when you add columns or change constraints.
If there are no foreign keys using JOINs, fields can become nullable, etc.
I made a simple example:
https://holistic.dev/en/playground/5596577a-ad0e-40e6-a05b-e...
Remove -- before ALTER and see how the result of the type export will change.
But custdev showed that companies do not care about it.
They are ready to take Django/RoR/Laravel developers who know only ORM. Such developers are cheaper, they are easier to hire.
Some people also think that it's faster to develop this way :)
They prefer to start dealing with problems after they get on production DB.
They shift developer problems to DBA. There is research saying that the price of fixing a bug in production is on average 400 times the price of fixing it at the development stage.
Ok, the boss call the shots :) I had to make a pivot to DBA needs.
It was a bit upsetting at first, but then I realized that it was even simpler. You need to do a lot more tools for developers to make them feel comfortable.
A few words about open source.
At first, I used this AST parser for PostgreSQL
https://github.com/lfittl/libpg_query
But it's frozen on Postgresql 10. And we don't know if there'll be any updates.
No official AST parser for MySQL.
There's a hard way to get a bison/ANTLR grammar parser.
The only problem is that the grammar for these parsers was written by hand and is not related to the official MySQL repository.
For example, the vitess parser does not support the syntax of MySQL 8.0, and MySQL 5.7 does not support more than 40%.
There is also such a tool https://www.jooq.org/.
It supports some of its own generalized SQL syntax, which does not take into account the specifics of different databases.
Anyway, all hard work starts after you have the right AST parser in your hands. And if you don't spend all your time on it, it will be difficult for you to do something really interesting :(
PS: I removed the types exporting tool from the site a few days ago, along with texts explaining all the advantages of this tool to the developers :)
In a couple of weeks, I will transfer it to a separate domain, as a separate project.
Thank you for the write-up that was super interesting. If you don’t mind I have a question about the microservices. What is theit goal? Serving the data from the database? If not, then there is business logic you can’t Possibly generate, so what exactly do you generate?
But my application was to be able to use raw SQL queries instead of an ORM in an application. By statically analyzing the SQL queries, then you can, in a statically typed language, automatically type-check the parameters to and results of the queries. Combining that and an IDE like the Jetbrains ones, which provide intelligent SQL autocompletion/refactoring, then tbh., I think it would beat an ORM in terms of ergonomics. Some people like LINQ or various Haskell/Scala ORMs because they are type-safe. This would be totally natural to those who know SQL without the downsides of being totally unanalyzed and type-checked.
It would be like the clojure library called hugs, but with static type-checking.