Sorting by an embedded property no longer works in Ingalls RC1 [DATAREST-976]

[spring-projects-issues]

Stefan Gybas opened DATAREST-976 and commented

I have a JPA entity with embedded class and a corresponding PagingAndSortingRepository that is accessed using Spring Data REST. I like to sort by a property in the embedded class.

Please see https://github.com/sgybas/spring-data-sorting-bug for a repro. The test passes with Spring Boot 1.4.3 (Spring Data Hopper-SR) but fails with Spring Boot 1.5.0.RC1 (Spring Data Ingalls RC1). The test also passes if I sort by the entity's id so the problem only occurs with embedded classes

---

Affects: 2.6 RC1 (Ingalls)

Reference URL: https://github.com/sgybas/spring-data-sorting-bug

Referenced from: pull request #251, and commits 99f4953, 3c6f311, 5212d13, ffe96e4, 69c3937, 97bae7a, 0f9ee7d, c1fb7bf

Backported to: 2.6 GA (Ingalls)

1 votes, 14 watchers

[spring-projects-issues]

Alan Hay commented

Seeing same behaviour after updating from Hopper to Ingalls RC1.

Previously a sort could be applied on a property of a nested object (for example, an Embeddable or a @ManyToOne association) by specifying:

sort=nestedField.property

This no longer seems to work

[spring-projects-issues]

Mark Paluch commented

That issue will be fixed with Ingalls GA, see Pull-Request 251.

[spring-projects-issues]

Khaled Lela commented

I tried 3.0.0.M3 , But sort=nestedField.property,[asc|desc] still not working with me

[spring-projects-issues]

Thomas Schuh commented

Sorting with nested fields does not work in current version (1.5.7) of spring boot. Is there a workaround?

[spring-projects-issues]

Daniele Renda commented

I'm using the 3.0.2.RELEASE and I'm experiencing the issue. I'm looking for a property using the notation

property_subproperty

I debugged and the problem seems to be in the source code line 188 of JacksonMappingAwareSortTranslator:

if (associations.isLinkableAssociation(persistentProperty)) {
						return Collections.emptyList();
					}

This line return true and so empty the list that then later set the sort filter to null.

According to the question on https://stackoverflow.com/questions/42262846/spring-data-rest-sort-by-nested-property seems there are other people with the same issue.

Thanks

[spring-projects-issues]

Miroslav Kos commented

Same issue, same line found while debugging (2.6.8.RELEASE)

[spring-projects-issues]

Radu Vanciu commented

For the 2.6.9 RELEASE, I tested the issue and I can confirm that it works as expected (see Pull-Request 251). The nested sort is however restricted to properties annotated with @RestResource(exported=false) which in the documentation is specified as Sorting by linkable associations (i.e. resources to top-level resources) is not supported.

I found this implementation a bit too restrictive, and I am looking for a workaround as well, since we want both linkable association and the nested sorting. For example, we need the nested sorting to work for @ManyToOne properties which are implicitly fetch=FetchType.EAGER

The workaround I found so far is to create an extra read only property for sorting purposes only. Building on the example from https://stackoverflow.com/questions/42262846/spring-data-rest-sort-by-nested-property

@Entity(name = "Person")
@Table(name = "PERSON")
public class Person {

    // read only, for sorting purposes only
    @JsonIgnore // we can hide it from the clients, if needed
    @RestResource(exported=false, updatable = false, insertable=false) // read only so we can map 2 fields to the same database column
    @ManyToOne //implicitly fetch=FetchType.EAGER
    private Address address;

     // We still want the linkable association created to work as before so we manually override the relation and path
    @RestResource(exported=true, rel="address", path="address")
    @ManyToOne
    private Address addressLink;

The drawback for the proposed workaround is that we now have to explicitly duplicate all the properties for which we want to support nested sorting.

Are there other workarounds?

Would it be possible to configure the sort translator to relax the restrictions to properties with fetch=FetchType.EAGER associations?

[spring-projects-issues]

Daniele Renda commented

Any will to fix this problem? The issue is still closed. Thanks

[spring-projects-issues]

Mark Paluch commented

With Ingalls we changed the sorting behavior. It's possible to sort on nested object's properties, it's not possible to sort by association properties as they're seen from a REST perspective. You're not able to sort by properties of a referenced aggregate root if that one is exported

[spring-projects-issues]

Daniele Renda commented

Thanks for your explanation. Is there another way to accomplish this? Let's say I've a bean like this:

@Entity
public class Customer extends AbstractEntity {
      private String name;

      @ManyToOne(fetch = FetchType.LAZY, optional = true) 
      private Address address;
}

Typically in the GUI when I've a customer's table I want to sort by customer's properties, but I could also want to sort by address.name. Because address is exposed how am I supposed to accomplish to this if the sorting behaviour is changed?

Thanks

[spring-projects-issues]

Jens Fischer commented

We were facing the same problem (using Spring Boot 1.5.9 with Spring Data REST 2.6.9). The nested property that we tried to use for sorting was covered with a Jackson Mixin containing @JsonProperty(access = READ_ONLY). Removing this annotation lead to proper sorting behaviour for this nested property

[spring-projects-issues]

Antonio Petrelli commented

I noticed that the piece that excludes linkable associations (i.e. associations to entity exposes as resources via a repository) is due to the method:
JacksonMappingAwareSortTranslator.SortTranslator.mapPropertyPath
which says:

if (associations.isLinkableAssociation(persistentProperty)) {
return Collections.emptyList();
}

IMHO this has no sense, why do you need to exclude them?

[spring-projects-issues]

Antonio Petrelli commented

I just noticed that Daniele Renda said the exact same thing, sorry for the noise. However it still does not make sense to me

[spring-projects-issues]

anasofiapaixao commented

I stumbled upon the exact same issue and am extremely surprised this could be considered the expected behavior. At my job we went through the work of bumping our spring-boot version, I now regret it immensely and if I knew a version upgrade would result in the loss of basic, essential functionality with no viable alternative I would have never done it. There's dozens upon dozens of questions on stackoverflow from people desperate to do just this, with no answer or alternative that does not involve a multiplication of query methods and god knows how many if-elses in the frontend.

This was an essential feature

[spring-projects-issues]

Daniele Renda commented

I agree with anasofiapaixao, this is a very important feature. The issue is still in status "closed". Someone could ask for a revaluation and reopen it?