5.0.0

Compile time breaking of DataLoaderOptions

Back in version 4.0.0 we introduced immutability into the DataLoaderOptions class, which was a good thing.

However it left the old mutative set methods in place and made them immutable. This was a mistake. This leads to bugs at runtime

for example

DataLoaderOptions options = DataLoaderOptions.newOptions();
if (maxBatchSize != BatchLoader.UNSET_BATCH_SIZE) {
  options.setMaxBatchSize(maxBatchSize);
}
return options.setCacheMap(cache);

The above code would continue compile but the setMaxBatchSize would never take affected with the immutable support.

So to help address #190 version 5.0.0 has removed the set methods and require the Builder methods to be used to ensure that code that relied on the old mutative methods now break at compile time and not at runtime.

DataLoaders now can have names

A DataLoader can now have a name. Its nullable so that old code can still work but its preferred that DataLoaders are named. This will help in debugging and also in instrumentation.

If you register a DataLoader into a DataLoaderRegistry then the names must match otherwise it will be rejected at registration time.

A series of long standing deprecated DataLoaderFactory methods got removed here as well.

What's Changed

• Remove jcenter reference after sunset by @dondonz in #184
• add jmh testing with one initial performance test by @andimarek in #187
• adds explicit jmh dependency for the idea jmh plugin by @andimarek in #192
• OSGI - Make org.jspecify.* imports optional by @schulm in #194
• Breaking change - adds a name to a DataLoader by @bbakerman in #193
• Breaking change: using LongAdder instead of AtomicLong by @dfa1 in #186
• Breaking change - renaming old mutable setXX methods by @bbakerman in #191

New Contributors

• @schulm made their first contribution in #194

Full Changelog: v4.0.0...v5.0.0

4.0.0

Instrumentation support of DataLoaders

A new org.dataloader.instrumentation.DataLoaderInstrumentation has been added that is a callback to allow you to know when certain DataLoader actions start and when they finish.

        DataLoaderInstrumentation timingInstrumentation = new DataLoaderInstrumentation() {
            @Override
            public DataLoaderInstrumentationContext<DispatchResult<?>> beginDispatch(DataLoader<?, ?> dataLoader) {
                long then = System.currentTimeMillis();
                return DataLoaderInstrumentationHelper.whenCompleted((result, err) -> {
                    long ms = System.currentTimeMillis() - then;
                    System.out.println(format("dispatch time: %d ms", ms));
                });
            }

            @Override
            public DataLoaderInstrumentationContext<List<?>> beginBatchLoader(DataLoader<?, ?> dataLoader, List<?> keys, BatchLoaderEnvironment environment) {
                long then = System.currentTimeMillis();
                return DataLoaderInstrumentationHelper.whenCompleted((result, err) -> {
                    long ms = System.currentTimeMillis() - then;
                    System.out.println(format("batch loader time: %d ms", ms));
                });
            }
        };
        DataLoaderOptions options = DataLoaderOptions.newOptions().setInstrumentation(timingInstrumentation);
        DataLoader<String, User> userDataLoader = DataLoaderFactory.newDataLoader(userBatchLoader, options);

Immutable classes

Some of the key classes like org.dataloader.DataLoaderOptions have been made immutable so as to provide more surety in how they get used and transformed. This is technically a breaking change if you code relied on the old mutability, however on balance we think this is a better code position to be in.

What's Changed

• Update version to 3.4.0 by @dondonz in #168
• Add stale bot by @dondonz in #169
• Removing unused slf4j references by @dondonz in #170
• Parameterise more tests across DataLoader implementations by @AlexandreCarlton in #171
• Allow ValueCache to work with Publisher DataLoader by @AlexandreCarlton in #172
• Transform support for DataLoaders by @bbakerman in #174
• Making DataLoaderOptions immutable by @bbakerman in #176
• Instrumentation support for dataloader by @bbakerman in #175
• add jspecify by @andimarek in #180
• Fixed a bug that the Spring team found by @bbakerman in #181
• Added a instrumentation of load calls by @bbakerman in #178
• Added support for a delegating data loader by @bbakerman in #182
• Update documentation for new release by @dondonz in #183

New Contributors

• @andimarek made their first contribution in #180

Full Changelog: v3.4.0...v4.0.0

v3.4.0

Thanks to everybody who contributed to this release of Dataloader!

With this release, this library changed from using Java 8 to Java 11.

What's Changed

• Remove CacheMap#containsKey before #get by @AlexandreCarlton in #146
• Verify a throwing CacheMap#get does not break DataLoader by @AlexandreCarlton in #147
• Bump to Java 11 by @AlexandreCarlton in #150
• Bump JUnit 4.x to JUnit Jupiter 5 by @AlexandreCarlton in #152
• Add a proof-of-concept for "Observer-like" batch loading by @AlexandreCarlton in #148
• Parameterise DataLoaderTest on DataLoader by @AlexandreCarlton in #153
• Migrate publisher tests by @AlexandreCarlton in #155
• Making the Subscribers use a common base class by @bbakerman in #154
• Make builds run on other branches by @bbakerman in #157
• More tests for Publishers on reactive branch by @bbakerman in #158
• Reactive streams branch move reactive classes out of dataloader helper by @bbakerman in #159
• Have MappedBatchPublisher take in a Set keys (and add README sections) by @AlexandreCarlton in #160
• A PR for reactive streams support by @bbakerman in #151
• Tweaked readme by @bbakerman in #161
• Update version in readme by @dondonz in #165
• Add support for batch loading of a Map of key-value pairs. by @Hc747 in #166
• Modernise/update Gradle configuration and misc. polishing. by @Hc747 in #167

New Contributors

• @Hc747 made their first contribution in #166

Full Changelog: v3.3.0...v3.4.0

3.3.0

What's Changed

• Pre-size resulting lists by @dfa1 in #142
• Minor javadoc fixes by @dfa1 in #141
• Shuts down executor if its was auto added by our code by @bbakerman in #144
• If there is a specific predicate for a dataloader - its is the final say on whether to dispatch by @bbakerman in #145

Full Changelog: v3.2.2...v3.3.0

3.2.2

What's Changed

A series of small fixes to make the code more efficient

• Lazily initialize Executor in ScheduledDataLoaderRegistry builder by @kilink in #135
• Avoid allocations in DataLoaderHelper.dispatch when there's no work by @kilink in #136

New Contributors

• @kilink made their first contribution in #135

Full Changelog: v3.2.1...v3.2.2

3.2.1

New ticker mode

There is a new mode in ScheduledDataLoaderRegistry called ticker mode that will continue to tick away and allow for chained data loader calls. See the readme for more details.

  ScheduledDataLoaderRegistry registry = ScheduledDataLoaderRegistry.newScheduledRegistry()
        .register("a", dataLoaderA)
        .register("b", dataLoaderB)
        .scheduledExecutorService(executorService)
        .schedule(Duration.ofMillis(10))
        .tickerMode(true) // ticker mode is on
        .build();

  CompletableFuture<Object> chainedCalls = dataLoaderA.load("user1")
        .thenCompose(userAsKey -> dataLoaderB.load(userAsKey));

Predicates per dataloader in ScheduledDataLoaderRegistry

ScheduledDataLoaderRegistry now has the capability to have a predicate per data loader specified as well as an overall one. This allows you to have fine control on when dataloaders get dispatched.

What's Changed

• Try.getThrowable - fixed incorrect exception message by @rstata in #122
• Prepend 0.0.0 to build version by @dondonz in #126
• Batch scheduler function support by @bbakerman in #128
• Adds a predicate to DataLoaderRegistry and a per dataloader map of pedicates is also possible by @bbakerman in #133
• Ticker mode on ScheduledDataLoaderRegistry by @bbakerman in #131

New Contributors

• @rstata made their first contribution in #122
• @dondonz made their first contribution in #126

Full Changelog: v3.2.0...v3.2.1

3.2.0

What's Changed

• Add context objects to StatisticsCollector methods by @AlexandreCarlton in #120
• Copy across valueCache in DataLoaderOptions copy constructor by @AlexandreCarlton in #121

New Contributors

• @AlexandreCarlton made their first contribution in #120

Full Changelog: v3.1.4...v3.2.0

3.1.4

What's Changed

• Changed Automatic Module Name to org.dataloader by @zrbrown in #118

New Contributors

• @zrbrown made their first contribution in #118

Full Changelog: v3.1.3...v3.1.4

3.1.3

What's Changed

• Configure Manifest task to create valid OSGi bundle by @Lana11s in #113
• Make NoOpStatisticsCollector to be default StatisticsCollector by @dugenkui03 in #112
• feat: make cache map values accesible for read only purposes by @samuelAndalon in #115

New Contributors

• @Lana11s made their first contribution in #113
• @samuelAndalon made their first contribution in #115

Full Changelog: v3.1.2...vv3.1.3

3.1.2

This fix release prevents excessive object allocation in the no-op ValueCache