Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support reading a sql file for @Query [DATAJDBC-230] #456

Closed
spring-projects-issues opened this issue Jul 1, 2018 · 4 comments
Closed

Support reading a sql file for @Query [DATAJDBC-230] #456

spring-projects-issues opened this issue Jul 1, 2018 · 4 comments
Assignees
Labels
in: repository status: declined type: enhancement

Comments

@spring-projects-issues
Copy link

@spring-projects-issues spring-projects-issues commented Jul 1, 2018

Toshiaki Maki opened DATAJDBC-230 and commented

It would be useful if we can use a sql file for @Query from a view point of maintenancebility.

package com.example.foo;

public interface FooRepository extends CrudRepository<Foo, Integer> {
  @Query(file = true)
  List<Foo> findBySql();
}

The corresponding sql file will locate at src/main/resources/com/example/foo/FooRepository/findBySql.sql as same as MyBatis.

In future, it would be great to support template engines for dynamic queries.


Referenced from: pull request #77

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Jul 1, 2018

Oliver Drotbohm commented

I'd like to veto this for now as it's basically an alternative for a properties file based query declaration mechanism that we already support in other modules. I am not sure Spring Data JDBC already supports that but I'd rather add support for that than introducing yet another query externalization mechanism.

Also, please note that we already have MyBatis support, which is probably the better alternative as it allows more flexible query declarations an mapping definitions

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Jul 2, 2018

Toshiaki Maki commented

@olivergierke

Thanks for your feedback.

I will also try that approach (maybe in another pull request).
But I think "sql file per query" is more straightforward for JDBC and easier to use than existing META-INF/xxxx-named-queries.properties since SQL tends to be long and might not be suitable for storing in one file and the file could be also executable.
I agree with MyBatis for dynamic queries for now but using MyBatis only for simple queries could be a bit painful

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Jul 2, 2018

Oliver Drotbohm commented

While I generally agree with the rationale, we also have to make sure that we do not drown developers in a ton of different ways to achieve the same thing. Spring Data JDBC is a special module as it's pretty focused in it's features and rather recommmends to use other libraries to create and manage SQL statements (jOOQ, MyBatis, Querydsl).

I.e. I'd argue that if you have SQL statements exceeding a certain level of complexity, the concern of how to organize them in files is already outweighed by the need to properly manage them anyway which would lead you to any of the aforementioned libraries.

There's nothing preventing us from adding the suggested support later, but I'd like to start with a very Spring Data consistent way of externalizing queries first collecting further feedback how the transition from that to one of the bespoke libraries went

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Jul 16, 2018

Jens Schauder commented

As argued by Oliver we should first look at supporting property files as the source for queries.

I created an issue for that: DATAJDBC-234

I'm willing to revisit this at a later point in time when the feature above is available to the public for some time and we have some feedback on it

@spring-projects-issues spring-projects-issues added status: declined in: repository type: enhancement labels Dec 31, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: repository status: declined type: enhancement
Projects
None yet
Development

No branches or pull requests

2 participants