Subobjects inserted with null values with Elasticsearch and DTOs

Overview of the issue

While creating a entity, it is saved both to the database and to Elasticsearch by the EntityServiceImpl’s save method. While creating an entity, all sub-objects are only saved with their ID, all other fields are null. When the entity is updated, all fields are present.

Motivation for or Use Case

This results into an incomplete state in Elasticsearch and can even produce functional problems, e.g. when the search should include fields of linked entities.

Reproduce the error

1. Create a new entitiy
2. Look into Elasticsearch index or try to search for content present in a field of a linked entity.

Related issues

n/a

Suggest a Fix

We found out that:

1. While creating an object, after entity = einsatzortRepository.save(entity); entity still contains incomplete fields (as it was received / mapped from the DTO)
2. While updating an object, after entity = einsatzortRepository.save(entity); entity has been filled from the database

We only have a workaround for our bug and did not come up with a real idea for a fix yet. The workaround is: If the EntityResource calls save() on the service twice, the data is persisted in Elasticsearch correctly.

JHipster Version(s)

4.6.2

JHipster configuration

.yo-rc.json:

{
  "generator-jhipster": {
    "promptValues": {
      "packageName": "de.XXXX",
      "nativeLanguage": "de"
    },
    "jhipsterVersion": "4.6.2",
    "baseName": "xxxx",
    "packageName": "de.XXXX",
    "packageFolder": "de/XXXX",
    "serverPort": "8080",
    "authenticationType": "oauth2",
    "hibernateCache": "no",
    "clusteredHttpSession": false,
    "websocket": false,
    "databaseType": "sql",
    "devDatabaseType": "h2Memory",
    "prodDatabaseType": "oracle",
    "searchEngine": "elasticsearch",
    "messageBroker": false,
    "serviceDiscoveryType": false,
    "buildTool": "maven",
    "enableSocialSignIn": false,
    "clientFramework": "angularX",
    "useSass": true,
    "clientPackageManager": "yarn",
    "applicationType": "monolith",
    "testFrameworks": [
      "protractor"
    ],
    "jhiPrefix": "jhi",
    "enableTranslation": true,
    "nativeLanguage": "de",
    "languages": [
      "de"
    ]
  }
}

Entity configuration(s) entityName.json files generated in the .jhipster directory

main.json

{
    "fluentMethods": true,
    "relationships": [
        {
            "relationshipType": "many-to-one",
            "relationshipValidateRules": "required",
            "relationshipName": "otherEntity",
            "otherEntityName": "otherentity",
            "otherEntityField": "name"
        }
    ],
    "fields": [
        {
            "fieldName": "name",
            "fieldType": "String",
            "fieldValidateRules": [
                "required",
                "minlength",
                "maxlength",
                "pattern"
            ],
            "fieldValidateRulesMinlength": 2,
            "fieldValidateRulesMaxlength": 50,
            "fieldValidateRulesPattern": "^[A-ZÄÖÜa-zäöüß\\- ]*$"
        },
       // ,,,
    ],
    "changelogDate": "20170704124210",
    "entityTableName": "eso",
    "dto": "mapstruct",
    "pagination": "infinite-scroll",
    "service": "serviceImpl"
}

Browsers and Operating System

Unrelated.

• Checking this box is mandatory (this is just to show you read everything)

[stieler-it]

Since this problem came up again we had to find a solution without re-writing the search functionality from scratch.

Basicall, in every Mapper, instead of:

    default Office fromId(Long id) {
        if (id == null) {
            return null;
        }
        Office office = new Office();
        office.setId(id);
        return office;
    }

we now have:

    public Office fromId(Long id) {
        if (id == null) {
            return null;
        }
        return officeRepository.findOne(id);
    }

This probably means some database calls that would not be necessary. However, every saved entity contains all its nested objects. This will save as from a bunch of bugs that would have been reported otherwise.

What do you think?

[pascalgrimaud]

@sdyson : I understand the need, but if you read the previous comment, it has been closed simply because no one wants to try to implement something. So maybe it’s minor or people don’t care about this issue.

Anyway, you’re welcome to propose a solution here 😃