Skip to content

Add additional tests for verifying persistence of related entities with assigned ids. #2346

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
LGDOI opened this issue Aug 2, 2021 · 2 comments
Assignees
Labels
status: duplicate A duplicate of another issue type: bug A general bug

Comments

@LGDOI
Copy link

LGDOI commented Aug 2, 2021

Given entities Application and Workflow where they have one-to-many relationship: (:Application)-[:CONTAINS_WORKFLOW]->(:Workflow)

In Java, Application has outgoing relationship to List. Workflow has incoming relationship to Application.

    val application1 = ApplicationStub.getOne(id = "app-1")
    val application2 = ApplicationStub.getOne(id = "app-2")

    val workflow1 = WorkflowStub.getOne(id = "wf-1", application = application1)
    val workflow2 = WorkflowStub.getOne(id = "wf-2", application = application2)

    application1.workflows = listOf(workflow1)
    application2.workflows = listOf(workflow2)

The above Kotlin code wires up both relationships.

In order to create graph correctly I can run either one of the following save methods.

//    listOf(application1, application2).forEach(applicationRepository::save)
// or
//    listOf(workflow1, workflow2).forEach(workflowRepository::save)

But, none of the following saveAll creates four nodes but no relationships are created b/w Application and Workflow

//    applicationRepository.saveAll(listOf(application1, application2))
//    applicationRepository.saveAll(listOf(application1))
//    workflowRepository.saveAll(listOf(workflow1, workflow2))
//    workflowRepository.saveAll(listOf(workflow1))

Also, tried uncommenting the following "BOTH" saveAll calls. But, this did not work either.

//    applicationRepository.saveAll(listOf(application1, application2))
//    workflowRepository.saveAll(listOf(workflow1, workflow2))

There seems a bug in saveAll method. Should we expect the save and saveAll behaves in the same manner.

Note: We use SDN v6.1.3.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Aug 2, 2021
@LGDOI
Copy link
Author

LGDOI commented Aug 2, 2021

Further troubleshooting narrowed down to specifying id on Workflow causes broken relationship.
Changed the workflow creation without id.

    val workflow1 = WorkflowStub.getOne(application = application1)
    val workflow2 = WorkflowStub.getOne(application = application2)

Then, saveAll works.

    applicationRepository.saveAll(listOf(application1, application2))

Or, saveAll workflows by not giving id on Application works as well.

    val application1 = ApplicationStub.getOne()
    val application2 = ApplicationStub.getOne()
    val workflow1 = WorkflowStub.getOne(id = "wf-1", application = application1)
    val workflow2 = WorkflowStub.getOne(id = "wf-2", application = application2)

    application1.workflows = listOf(workflow1)
    application2.workflows = listOf(workflow2)

    workflowRepository.saveAll(listOf(workflow1, workflow2))

@michael-simons michael-simons self-assigned this Aug 9, 2021
@michael-simons
Copy link
Collaborator

This is actually the same issue that is behind #2347. Two for the price of one, thanks a ton for your reports. 👍

@michael-simons michael-simons added type: bug A general bug status: duplicate A duplicate of another issue and removed status: waiting-for-triage An issue we've not yet triaged labels Aug 10, 2021
@michael-simons michael-simons added this to the 6.0.12 (2020.0.12) milestone Aug 10, 2021
@michael-simons michael-simons changed the title Investigate why saveAll does not save relationships Add additional tests for verifying persistence of related entities with assigned ids. Aug 10, 2021
michael-simons added a commit that referenced this issue Aug 10, 2021
…ntities with assigned ids.

There is no need for an additional fix, the root cause had been addressed in #2347 already.

This closes #2346.
michael-simons added a commit that referenced this issue Aug 10, 2021
…ntities with assigned ids.

There is no need for an additional fix, the root cause had been addressed in #2347 already.

This closes #2346.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: duplicate A duplicate of another issue type: bug A general bug
Projects
None yet
Development

No branches or pull requests

3 participants