Repository navigation
DataLoaderOptions immutability change is not breaking #190
Description
Discussed in #188
Originally posted by zsmoore April 30, 2025
Hello all,
We are upgrading to 4.0.0 to get the latest instrumentation changes (thank you this will remove some custom infra we have). However, after the upgrade we have failing tests due to the immutability change.
This is fine as its a major change and we expect to need changes however the immutability change seems like we could go farther here. I agree that we should ditch the mutability and move to immutability however, since this is a major change anyway should we have just deleted the old functionality? Now code that does not have test coverage might break at runtime rather than compile time. Luckily we had test coverage to cover this scenario.
example code
DataLoaderOptions options = DataLoaderOptions.newOptions();
if (maxBatchSize != BatchLoader.UNSET_BATCH_SIZE) {
options.setMaxBatchSize(maxBatchSize);
}
return options.setCacheMap(cache);
In this case I would prefer if the codebase was broken so we could make the proper fix rather than needing to find it ourselves based on the test results.
Thank you!
Activity
bbakerman commentedon May 1, 2025
We have had the same feedback from a team in Atlassian.
This was a mistake - we meant to break the behavior to be immutable but I wrongly kept the API shape the same but this was wrong. Mea cupla.
We will release a v5.0 very soon with this fixed since it will continue to hurt others over time. So any one using DataLoader direct would be able to get the new breaking change and file at compile time.
Our challenge however is more in graphql-java. We updated to 4.0 as a transitive dependency and if we were to pick up this new major version then really that should be a major release of graphql-java and we only just made one of those
So we need to decide if this is worth a major graphql-java release or not. But thats a seperate decision to a new DL major version
dondonz commentedon May 12, 2025
Addressed in #191