Uploaded image for project: 'Spring Data Commons'
  1. Spring Data Commons
  2. DATACMNS-937

Support for Javaslang's Option as return type of query methods

    Details

      Description

      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: https://github.com/spring-projects/spring-data-commons/pull/184

        Activity

        Hide
        olivergierke Oliver Gierke added a comment -

        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.

        Show
        olivergierke Oliver Gierke added a comment - 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.
        Hide
        dwelch2344 David Welch added a comment -

        +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.

        Show
        dwelch2344 David Welch added a comment - +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.
        Hide
        olivergierke Oliver Gierke added a comment -

        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).

        Show
        olivergierke Oliver Gierke added a comment - 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).
        Hide
        olivergierke Oliver Gierke added a comment -

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

        Show
        olivergierke Oliver Gierke added a comment - That's in place now. Feel free to give the snapshots a spin.

          People

          • Assignee:
            olivergierke Oliver Gierke
            Reporter:
            roadrunn Darek Kaczynski
            Last updater:
            Oliver Gierke
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: