Skip to content

Add ImmutableBeanCache - some parts of the query result graph populated via ImmutableBeanCache#3753

Merged
rbygrave merged 12 commits into
masterfrom
feature/lazy-load-byType-part-2
May 6, 2026
Merged

Add ImmutableBeanCache - some parts of the query result graph populated via ImmutableBeanCache#3753
rbygrave merged 12 commits into
masterfrom
feature/lazy-load-byType-part-2

Conversation

@rbygrave
Copy link
Copy Markdown
Member

@rbygrave rbygrave commented Apr 23, 2026

An example:

  1. Define a FetchGroup - this controls what is in each cache entry.
    // Label with associated labelTexts

    FetchGroup<Label> fetchGroup = FetchGroup.of(Label.class)
      .select("version")
      .fetch("labelTexts", "locale, localeText")
      .build();
  1. Define a ImmutableBeanCache - using a built in implementation
ImmutableBeanCache<Label> labelCache = ImmutableBeanCaches.builder(Label.class)
  .loading(database, fetchGroup)
  .maxSize(10_000)
  .maxIdleSeconds(300)
  .maxSecondsToLive(6_000)
  .build();
  1. Use the cache in a query
    AttributeDescriptor one = database.find(AttributeDescriptor.class)
      .setId(heightDescriptor.id())
      .setUnmodifiable(true)
      .using(labelCache) //  <!-- HERE 
      .findOne();

The Label instance that are part of resulting graph are Unmodifiable and populated from the labelCache.

Another example

FetchGroup<Customer> customerGroup = FetchGroup.of(Customer.class)
  .select("name,version")
  .fetch("billingAddress", "line1,city")
  .fetch("shippingAddress", "line1,city")
  .build();

ImmutableBeanCache<Customer> customerCache = ImmutableBeanCaches.builder(Customer.class)
  .loading(database, customerGroup)
  .build();
 database.find(Order.class)
  .using(customerCache)
  ...
  .findList()

rbygrave added 10 commits April 21, 2026 23:49
We have some graph models where a common type (in the tests it is Label)
is used in many different *paths* of the graph. When we are loading via
*path* then all the loading of the Labels isn't in a single batch / load context
but instead split into different load contexts PER PATH.

This change, means that lazy loading operates by TYPE instead of by PATH.

In the tests, all the Labels are read via a single lazy loading query rather
that one lazy loading query per PATH, and this is more efficient.
…onal

Using positional avoids the lookup by property name.
…tation

This provides a cache with maxSize, maxIdleSeconds, maxSecondsToLive
@rbygrave rbygrave self-assigned this Apr 23, 2026
@rbygrave rbygrave changed the title Feature/lazy load by type part 2 Add ImmutableBeanCache - some parts of the query result graph populated via ImmutableBeanCache Apr 23, 2026
rbygrave added 2 commits May 1, 2026 00:22
 - add ImmutableBeanCache.getIfPresent() as a non-loading probe
 - use immutable cache hits in AssocOneHelp / AssocOneHelpRefInherit
 - avoid creating ref beans and merge/copy for unmodifiable cache hits
 - keep existing mutable-query and miss/backfill behavior unchanged
@rbygrave rbygrave added this to the 16.6.0 milestone May 6, 2026
@rbygrave rbygrave merged commit 4dde706 into master May 6, 2026
1 check passed
@rbygrave rbygrave deleted the feature/lazy-load-byType-part-2 branch May 6, 2026 10:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant