Neo4j relation rework

[Evertude]

When a Neo4J entity has relations, two findAll methods are created in the service: One without parameters and one with a Pageable.

    /**
     * Get all the items.
     *
     * @return the list of entities.
     */
    public List<Item> findAll() {
        log.debug("Request to get all Items");
        return itemRepository.findAllWithEagerRelationships();
    }

    /**
     * Get all the items with eager load of many-to-many relationships.
     *
     * @return the list of entities.
     */
    public Page<Item> findAllWithEagerRelationships(Pageable pageable) {
        return itemRepository.findAllWithEagerRelationships(pageable);
    }

Currently there is no findall method in the repository without parameters so it is added in this PR.

---

Please make sure the below checklist is followed for Pull Requests.

• All continuous integration tests are green
• Tests are added where necessary
• jhipster-online was updated if necessary
• Documentation is added/updated where necessary
• Coding Rules & Commit Guidelines as per our CONTRIBUTING.md document are followed

When you are still working on the PR, consider converting it to Draft (bellow reviewers) and adding skip-ci label, you can still see CI build result at your branch.

[CLAassistant]

All committers have signed the CLA.

[DanielFran]

@Evertude Can you add tests please?

[Evertude]

I'm currently reworking the whole neo4j entity creation process because it doesn't work (for me) so it might take a bit.

I'm not familiar with your testing infrastructure but as far as I understood, the tests only involve "Files are created".
Do you have any code that compiles the created projects and runs the tests within them?

[atomfrede]

I think Daniel is referring to a generated tests in the application. So the integration tests will have a tests making sure everything works as expected (can't see the code as I am on my Mobile).

[Evertude]

Well, the tests already exist. The problem is that the code doesn't compile in the first place.

[Evertude]

Finished the relationship rework.

Before:
One-to-many relations don't create directed database relations and instead create relation loops between nodes
This results in recursions when querying data which lead to heap overflow

After:
Relations are properly directed and use Neo4J naming scheme

Additionaly:
Removed the eager loading stuff to avoid confusion because it is the default with Spring Data Neo4j

[Evertude]

related to jhipster/jhipster-bom#79

[DanielFran]

If there is a different nomenclature for relationship name, the rule should be applied where it is calculated?

[Evertude]

I think this nomenclature should only apply to the database mapping itself and this is the first time it is calculated

https://neo4j.com/docs/cypher-manual/current/syntax/naming/#_recommendations

[Evertude]

Otherwise it would be also used in the front end

[DanielFran]

@Evertude I was talking to calculate it directly on function prepareRelationshipForTemplates, but @mashima can confirm if it is the correct function.

[DanielFran]

@mshima @atomfrede If we re-calculate this relationship name here, this can be an issue due to the size of the relationship length (we are adding more 4 characters HAL_)?

[mshima]

Hard to say, this is a neo4j exclusive feature and there is no neo4j test workflow to see if it works.
I know for sure that those won't be propagated to others generators and templates, and changing the main relationshipName will break others generators like frontend.
I will let neo4j experts to decide.

[DanielFran]

If there is a different nomenclature for relationship name, the rule should be applied where it is calculated?

[DanielFran]

The condition should be OR this.context.databaseType === 'neo4j'?

[Evertude]

Since the default for Spring Data Neo4J is eager loading, I thought it doesn't make sense to create additional code like findAllWithEager which this flag determines. That's why I turned it to false if the databaseType is neo4j

[Evertude]

Alternative would be to override the default findAll method with lazy loading and add the eager loading ones. Could do that if you want me to

[DanielFran]

@mshima @atomfrede If we re-calculate this relationship name here, this can be an issue due to the size of the relationship length (we are adding more 4 characters HAL_)?

[DanielFran]

@Evertude can you fix the conflicts?

@atomfrede did you have time to review the PR?

[atomfrede]

Looks fine but didn't found time to test it.

[Evertude]

Merged by using my version with removed findAllEager methods.

A note for the future: The query that you used wouldn't work as intended anyways because the MATCH statement requires an existing relation to another entity to return a result. The findAll wouldn't return entities that don't have relations

[mraible]

@Evertude Please fix conflicts and let's merge this!

[Evertude]

@DanielFran The maximum relationship length in Neo4J is 65k, I doubt that the 4 more characters make a difference: https://neo4j.com/docs/cypher-manual/current/syntax/naming/

[DanielFran]

@Evertude trusting you on this.
@atomfrede Since the Neo4J e2e tests are broken for a while, I merge it.

[Evertude]

While working with M:N relationships, I realized that the OGM has pretty weird behavior when saving entities.
It sometimes doesn't add relations and even removes relations from other entities.

I read up a little and it seems like you are supposed to use RelationEntities for m:n relations.
That would require a sizeable re-implementation of the generator though.

For now I don't really have a solution and I don't know if its worse to randomly delete and not add stuff or to run in an infinite loop but at least my contribution should fix 1:N relations and M:N reads.

Please keep the Beta flag lol