Actually, Hibernate provides some means to restrict the number of attributes fetched - you can list the attributes in the “select” clause of your JPQL explicitly. But the result of such query will be a flat structure - a map or a DTO. So you won’t be able to map the result to an object graph. Apparently such flat structures can be used instead of graphs - but I think it’s not Java way.
To be honest, I wasn’t aware of Spring Data until now. Its approach for facilitating data access looks great if your business logic has some frequently repeated data loading patterns. One of my colleagues has confirmed that he used Spring Data in experiments, so most probably you can use it in CUBA middleware as is. But you will definitely lose our “views” mechanism and hence partial entities mentioned above.
Another option would be to implement a similar “higher abstraction layer” on top of CUBA JPQL Query. It doesn’t seem difficult to create dynamic proxies for interfaces with methods with descriptive names or annotations and create JPQL under the hood. In this case, our views mechanism can be fully employed, as well as all other non-standard features. For example, in the future EclipseLink-based version of CUBA entity listeners are completely reimplemented on CUBA layer because the standard implementation is too dumb to be useful.
If you go for integrating Spring Data, please start another topic for further discussion of and related issues. I’m going for vacations and will be completely unplugged for 2 weeks, but my colleagues will help you in case of troubles with integration.
By the way, if you prefer Groovy over Java (which I can conclude from your experience), you can code in Groovy when creating CUBA screen controllers and middleware beans. If you are interested, again, please start a new topic and we will help you to configure the project.