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 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.
Two weeks ago there was a parser like this for MySQL: https://github.com/stevenmiller888/ts-mysql-parser.
There's also a parser from vitess: https://github.com/vitessio/vitess/tree/master/go/vt/sqlpars...
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.
Look, there is another tool that uses libpg_query - sqlc: https://news.ycombinator.com/item?id=21765689.
And the author of ts-mysql-parser also offers an analyzer: https://github.com/stevenmiller888/ts-mysql-analyzer There are only four rules at the moment...
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.
I am open to personal communication outside this site, all my contacts are at https://holistic.dev/en/contacts/