1

I am trying to build an item -> details page on my application involving entities EcmOrder ->> EcmOrderItem -> Product as described below:

JDL model fragment:

EcmOrder to EcmOrderItem 1:N relationship

By using side by side techniques, I extended the repository, service and resource classes on back end. The extended EcmOrder repository has a new "find" method which eagerly fetches the associated EcmOrderItem and Product data:

@Repository
public interface EcmOrderRepositoryEx extends EcmOrderRepository {
    @Query("select ecmOrder "
         + "from EcmOrder ecmOrder "
         + "join fetch ecmOrder.ordOits ecmOrderItem "
         + "left outer join fetch ecmOrderItem.oitPro product where ecmOrder.id =:id")
    Optional<EcmOrder> findOneWithEagerRelationships(@Param("id") Long id);
}

On the front end, I extended various elements and changed the html template to accommodate the additional data that now comes embedded into the incoming order data.

The page has the following aspect:

EcmOrder detail page

The problem is that the repository query gets all the data, including the EcmOrder, all EcmOrderItems and Product for each EcmOrderItem but json serialized data that arrives in the browser does not include the Product data, thus leaving the "Oit Pro" column blank, as evidenced by the browser snapshot below:

Data arriving for order detail request

So my question has two parts:

  1. I guess this is probably related to @JsonIgnoreProperties used by JHipster on the entities java classes but tampering with that is the correct way to go?

  2. Is there a way to solve this problem while avoiding changes to JHipster generated files, i.e., only adding my code?

1 Answers1

0

Q1: of course you could change the generated class, it's your code of course. I see the point in not wanting to go that way as every adaption of generated code makes migration harder. A solution could be to write a test which tests for the presence of the desired property in JSON. That would be helpful if you migrate to a newer jhipster version and forget to migrate the removal of that annotation.

I see one point which could still be an issue though. If you remove that annotation it could fail as all lazy one-to-many relations need an active transaction to lazy-load the related entities when the getter is called. If that is done when Jackson is serializing the response you don't have a transaction anymore thus potentially leading to an exception stating that. But this is just a guess. Give it a try.

Q2: There is the possibility to use Jackson MixIns and configure them at the objectmapper which you can do without interfering with the generated code (see https://stackoverflow.com/a/66023857/4227570). However I'm not sure if disabling @JsonIgnoreProperties can be overridden by MixIns.

Another approach could be to use Jhipster with DTOs ( https://www.jhipster.tech/using-dtos/). I just saw that they directly address the transactional issue in that document "... if you are using JPA, this is because the service layer is transactional, so lazy-loading will work". If using that feature Jhipster creates DTOs and uses them in the for serialization. Makes things more complex though, but it might be worth the approach.