Skip to content

findAll() doesn't load child relations for children extending an abstract class #2783

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

Closed
Soamid opened this issue Aug 28, 2023 · 1 comment
Closed
Assignees
Labels
status: needs-investigation An issue that has been triaged but needs further investigation

Comments

@Soamid
Copy link

Soamid commented Aug 28, 2023

I'm using SDN and Neo4j a lot in my project and everything was fine so far, but recently I've encountered strange behaviour. Basically, I created a model consisting of 3 entities connected in the chain: A -rel1-> B -rel2-> C. I added the default Spring Neo4j repository for A entity, filled the database and tried to call aRepository.findAll(). I obtained the result: A -rel1-> B -rel2-> null, C was missing.

It took me several hours to find the root of this problem. Everything was stored correctly in the DB, generated queries looked correct, and the C object was returned in the json results. But somehow it was lost in mapping to the object model. Eventually, I realized it was a problem with the model structure. Class B extends another class, which is abstract. While digging with the debugger I found DefaultNeo4jPersistentEntity#getMostAbstractParent() method which is used to generate key describing data in the mapping process. When an entity has an abstract parent, the relation is resolved as "parent_rel_C" instead of "B_rel_C" (which is the real key in the returned data!).
Moreover, when I load the relationship more directly, by B repository, C is loaded as intended, because an abstract parent is not searched when you process the main entity (this is returned in the aforementioned getMostAbstractParent()).

I think that's the cause of my problem, but I still don't understand why it works that way (and didn't find a mention of it in the documentation). Or maybe it's just a bug. I don't know, but would be grateful for clarification and advice what to do. :)

I've created a small example of the problem:

@Node("A")
public class A {

  @Id
  private final UUID id;

  @Relationship(value = "connectsB", direction = Relationship.Direction.OUTGOING)
  private final B bRelation;

  @PersistenceCreator
  public A(UUID id, B bRelation) {
    this.id = id;
    this.bRelation = bRelation;
  }

  public B getBRelation() {
    return bRelation;
  }
}
public class B extends BParent {

  @Id
  private final UUID id;

  @Relationship(value = "connectsC", direction = Relationship.Direction.OUTGOING)
  private final C cRelation;

  @PersistenceCreator
  public B(UUID id, C cRelation) {
    this.id = id;
    this.cRelation = cRelation;
  }

  public C getCRelation() {
    return cRelation;
  }
}
public class BParent {
}
public interface ARepository extends Neo4jRepository<A, UUID> {
}
  @Test
  void testA() {
    var c = new C(UUID.randomUUID());
    var b = new B(UUID.randomUUID(), c);
    var a = new A(UUID.randomUUID(), b);
    aRepository.save(a);

    List<A> aResults = aRepository.findAll();

    assertEquals(1, aResults.size());
    assertNotNull(aResults.get(0)
        .getBRelation());

   // this assertion fails
    assertNotNull(aResults.get(0)
        .getBRelation()
        .getCRelation());
  }

If you remove the abstract modifier from the BParent class, the test passes.

I'm using Spring Boot 2.7.8 with Neo4j starter (SDN 6.3.7). I wasn't able to check it in the newer versions of the SDN because of some compatibility issues with newer Spring, but at least DefaultNeo4jPersistentEntity code seems unchanged when I checked.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Aug 28, 2023
@meistermeier meistermeier self-assigned this Sep 15, 2023
@meistermeier meistermeier added status: needs-investigation An issue that has been triaged but needs further investigation and removed status: waiting-for-triage An issue we've not yet triaged labels Sep 15, 2023
@meistermeier
Copy link
Collaborator

Thanks for reporting this and sorry for missing it in the first place.
I am pretty sure it is related to #2819 Basically the same problem here but without the use of projections.
There is a fix mentioned in the issue:
6.3.14-GH-2819-SNAPSHOT
or, if you on a newer version
7.2.0-GH-2819-SNAPSHOT
will close this issue now and try to keep the focus on the linked on for feedback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: needs-investigation An issue that has been triaged but needs further investigation
Projects
None yet
Development

No branches or pull requests

3 participants