Prototype a query by name method parser #523
Conversation
Signed-off-by: Scott M Stark <starksm64@gmail.com>
Signed-off-by: Scott M Stark <starksm64@gmail.com>
Signed-off-by: Scott M Stark <starksm64@gmail.com>
Signed-off-by: Scott M Stark <starksm64@gmail.com>
|
This has been updated to the latest code we are using to pass the TCK with Hibernate 6.6.0 |
Awesome. I hope everyone understands that this is something essentially any implementor of Jakarta Data can use to add support for QbMN. |
| Set<? extends Element> repositories = roundEnv.getElementsAnnotatedWith(Repository.class); | ||
| for (Element repository : repositories) { | ||
| String provider = repository.getAnnotation(Repository.class).provider(); | ||
| if(provider.isEmpty() || provider.equalsIgnoreCase("hibernate")) { |
There was a problem hiding this comment.
I hope everyone understands that this is something essentially any implementor of Jakarta Data can use to add support for QbMN.
Would this restrict the the use case of this tool to hibernate only?
I'd be interested in a README file to help understand the general use case of this tool for a Jakarta Data provider.
There was a problem hiding this comment.
Ah yes, that should be parameterized I guess.
|
I'll add a README and a parameterization of the provider value(s). The README can have sections for providers that have made use of it to document how it is used. |
|
Well, query method by name is regular grammar, something, that should be parsed by regular expression or state machine. Why to build this whole LL(k) context-freee grammar monster which needes at least recursive descend parser? It's nice to have some sample QbMN parser and some additional tooling, but keep in mind that this is specification + API project. |
|
Does it still need ? Can we close? |
5 participants
This prototypes a library tool that parses a Query by name method name using an Antlr4 generated parser and a grammar based on the current spec "BNF Grammar for Query Methods" section.