2

There is this JPA Entity (let's call it Foo) that I use to display on the FrontEnd. The Entity is linked to another entity by a join (Let's call it Bar).

So the backstory here is that I don't need Bar in the FrontEnd call (When calling the Foo Entity/ties), I only need it for a BackEnd call (When calling the Foo Entity/ties). Is there a way to conditionally exclude the joined Bar entity when calling Foo entities via the JPA FooRepository?

PS: Let's say one Foo entity is linked to a 1000 Bar entities and I don't want it to delay displaying in the FrontEnd because of entities that are not going to be useful in the FrontEnd.

The below is the JPA Entity for Foo

  public class Foo implements Serializable {

    @Id
    @Column(name = "id")
    private BigInteger id;

    @Column(name = "name")
    private String name;


    @OneToMany(cascade = CascadeType.ALL)
    @JoinColumns({
            @JoinColumn(name = "id" , referencedColumnName = "foo_id")
    })
    private List<Bar> barList;
    
 }

And this is the JPA Entity for Bar


  public class Bar implements Serializable {

    @Id
    @Column(name = "key")
    private BigInteger key;

    @Column(name = "foo_id")
    private BigInteger fooId;

    @Column(name = "back_code")
    private String backCode;

    @Column(name = "date_cap")
    private Date dateCap;

    @Column(name = "hash")
    private String hash;
    
 }

Below is the JPA Repository for Foo, with no custom methods, I am only using findAll() and findById()

public interface FooRepository extends JpaRepository<Foo, BigInteger>{
}
sephoro
  • 150
  • 10

1 Answers1

1

Mark barList with FetchType.Lazy

@OneToMany(fetch=FetchType.LAZY, ...)

That will make it not load the barList by default. In the method where you want to load barList you access the list somehow, for instance with calling its size()

@Transactional
public Foo getFullyPopulatedFoo(BigInteger key) {
  var foo = fooRepo.findById(key)
  foo.getBarList().size(); // may cause error if foo was not found
  return foo;
}

or by having a separate method to return its barList. Notice that loading the barList need to be done within the same transaction as fetching Foo, for instance in a service method.

@Transactional
public List<Bar> getBarsFromFoo(BigInteger key) {
  return fooRepo.findById(key).getBarList(); // may cause error if not found
}

What to consider is if it would be better to remap Foo / Bar to some sort of DTO before leaving the service/transaction layer since if you return Foo without populating barList, then you return an incomplete entity that may or may not have entries in the database but not in the entity you have returned.

Tomas F
  • 7,226
  • 6
  • 27
  • 36
  • 1
    Thank you for your detailed explanation @Tomas, as mentioned in the question I only need the ``Foo`` entity for external purposes (Displaying to the front-end) and the ``BarList`` is only affected by what's done to ``Foo`` in the front-end. So I don't need the ``FooDTO`` to have the ``BarList`` in the front-end. So as @Thomas explained in the comment to the question ,``BarList`` is lazily loaded by default, so there was no need for me to worry about it. I only need to alter ``BarList`` for a back-end call only of which his solution is simple and addresses my concerns. – sephoro Aug 13 '21 at 11:53