Class EagerFetchMappingTest

java.lang.Object
ubic.gemma.core.util.test.BaseTest5
ubic.gemma.core.util.test.BaseDatabaseTest5
ubic.gemma.persistence.hibernate.EagerFetchMappingTest
@ContextConfiguration public class EagerFetchMappingTest extends BaseDatabaseTest5
Pins the fetch mode of eager associations, which the hbm.xml to annotations migration changed.

In hbm.xml, lazy="false" with no fetch attribute meant fetch="select". On an annotation, FetchType.EAGER with no Fetch means FetchMode.JOIN. The port carried the first over as the second, naming no fetch mode, so 42 associations that hbm.xml loaded by a separate statement became outer joins on every by-id load, proxy initialization and batch load.

Two shapes of that are costly, and this test forbids both:

  • An eager collection fetched by join multiplies the rows of the statement that loads its owner, and every row carries every selected column. Two such collections on one entity multiply each other. SampleCoexpressionMatrix was loaded with one row per bioassay, each carrying the whole matrix; for GSE260875 that is 1,090 copies of a 9.5 MB blob per load.
  • A many-to-one fetched by join repeats the target's columns once per owner row. When the target carries a blob and owners are batch-loaded (128 per statement), the same blob is sent once per owner: SingleCellExpressionDataVector.singleCellDimension and the dimension's CELL_IDS.
HQL is not affected either way: it ignores the mapped fetch mode and loads eager associations it does not join fetch with a follow-up select.

An association that genuinely needs a join goes in the allow-list below, with its reason.

See Also:

  • Constructor Details

    • EagerFetchMappingTest

      public EagerFetchMappingTest()

  • Method Details

    • eagerCollectionsAreNotFetchedByJoin

      @Test public void eagerCollectionsAreNotFetchedByJoin()

    • manyToOnesFetchedByJoinDoNotTargetAnEntityWithABlob

      @Test public void manyToOnesFetchedByJoinDoNotTargetAnEntityWithABlob()