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 for Javaslang's Option as return type of query methods [DATACMNS-937] #1390

Closed
spring-projects-issues opened this issue Nov 18, 2016 · 4 comments
Assignees
Labels
type: enhancement
Milestone

Comments

@spring-projects-issues
Copy link

@spring-projects-issues spring-projects-issues commented Nov 18, 2016

Darek Kaczynski opened DATACMNS-937 and commented

Spring Data JPA supports JDK 8 and Guava Optional as well as Scala Option so far. Support for JavaSlang Option would be welcome as well.

The issue with JavaSlang is that javaslang.control.Option is an interface, not a class as in all other supported libraries. This in conjunction with compiler source level set to 1.6 rises a problem of calling a static method on an interface that is not supported until Java 1.8. Therefore one cannot simply add support for JavaSlang following the pattern in QueryExecutionConverters, as the compiler will not allow it.

Also current implementation of QueryExecutionConverters is completely closed to extensions. Everything is static and private. Although it's nice Spring Data supports some wrappers out of the box, it'd be even nicer if it allowed adding custom ones in runtime. It'd not be hard to implement using i.e. ServiceLoader.

I created example implementation here: #184


Referenced from: pull request #184

Backported to: 1.13 RC1 (Ingalls)

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Nov 18, 2016

Oliver Drotbohm commented

Thanks Derek. I am wondering whether we could create the Option instance via reflection to avoid the rather radical change proposed. I am not even saying, we should eventually end up making that particular path of the codebase for easier extension, I'd just like to decouple that from the JavaSlang support

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Nov 19, 2016

David Welch commented

+1 for opening to extension. We've got a (currently internal) SD implementation that utilizes raw SQL + JDBC. It works great, but getting around the issue of custom "bean" return types on query methods is pretty nasty. It'd be ideal to tap into some facade to determine how to return the object from the actual repository implementation.

Haven't checked out the PR yet but very interested to see it.

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Nov 19, 2016

Oliver Drotbohm commented

David Welch — Would you mind creating a separate ticket for that then? We're only going to introduce support for JavaSlang Option here. What I don't quite understand is why you don't just handle that stuff in your Spring Data implementation then as you actually could do that in contrast to the original poster.

Note that the conversion mechanism hasn't been made publicly configurable as there are other parts of the Spring Data world that need to unwrap those wrappers again (e.g. Spring Data REST) and handing a configurable instance of whatever this new API might look like through all the different parts of the system was quite cumbersome. So I can't guarantee that we're ever going to make this happen if it introduces too much complexity. Complexity that might not be obvious from only the changes in Spring Data Commons.

That said, I have a working prototype for JavaSlang integration here that works based on the current model. Needs some polishing though but will be ready for Ingalls RC1 (due late November)

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Nov 19, 2016

Oliver Drotbohm commented

That's in place now. Feel free to give the snapshots a spin

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement
Projects
None yet
Development

No branches or pull requests

2 participants