Shall JSQLParser support SQL Templates by allowing Named or Ordinal Parameters just anywhere

[manticore-projects]

Please see #2191 and vote YES or NO.

[manticore-projects]

@wumpz @AnEmortalKid @jxnu-liguobin @zaza @gitmotte @mj-db @minleejae @CeeKayGit @ted-johnson @tvar @cbockermann @nicky6s @georgekankava @ssteinhauser @OlivierCavadenti @davidjgoss @SheldonKubor

Please voice your opinion, thank you already!

[jxnu-liguobin]

There are similar requirements in graphql code generation libraries that I maintain, and the prerequisite for implementation is that the template is componentized and independent.

[manticore-projects]

There are similar requirements in graphql code generation libraries that I maintain, and the prerequisite for implementation is that the template is componentized and independent.

Thank you much, please leave your vote also. Appreciated.

[minleejae]

While having utility features like JDBC parameters support could be convenient, I feel it might blur the responsibility of the project.
It seems more appropriate for JSQLParser to focus solely on parsing valid SQL statements, without extending into template or utility functionalities.

[AnEmortalKid]

Voted. I think I’m on the side of:

• keep templating separate.

I could see the library evolving to become jSQL and it provides the parser module and the template module. Not sure how you can flex the grammar , maybe it’s easy to just copy paste the grammar and make edits to the template one.

[jxnu-liguobin]

Voted+1

[gitmotte]

There are powerful open source templating engines - just choose the right one for your case and process the source code with jsqlparser before parsing!

[manticore-projects]

Thank you all for the participation, interest and effort!