Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SLING-10502 - lazy loading helpers #25

Merged
merged 17 commits into from
Jun 24, 2021
Merged

Conversation

bdelacretaz
Copy link
Member

@bdelacretaz bdelacretaz commented Jun 21, 2021

This is an initial implementation with a LazyLoadingFieldand LazyLoadingMap that should help build GraphQL result sets with lazy loading values.

Copy link
Member

@raducotescu raducotescu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with all the observations that @jsedding made. There's no need to synchronize the LazyLoadingMap if it extends HashMap. Leave the synchronization to the caller - they can always wrap it in a Collections#synchronizedMap, or extend ConcurrentHashMap.

@bdelacretaz
Copy link
Member Author

Thank you for the detailed review, all good suggestions! Of course, HashMap not being synchronized it doesn't make sense to make the LazyLoadingMap thread safe, I have removed all synchronization in that class.

I think I have implemented all other suggestions, please cross-check.

Copy link

@jsedding jsedding left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@Override
public T remove(Object key) {
super.remove(key);
suppliers.remove(key);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be too expensive to obey the Map contract in this case?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's hard to say - I will make that optional, adding an Options object to the class constructor.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Committed that, using class methods to set options instead.

*/
private void computeAll() {
if(!suppliers.isEmpty()) {
log.info("computeAll called, all remaining lazy values will be evaluated now");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be logged on debug - I assume that with GraphQL in Sling catching on, we'll have a lot of LazyLoadingMaps.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 I'll do that

@sonarcloud
Copy link

sonarcloud bot commented Jun 24, 2021

Kudos, SonarCloud Quality Gate passed!

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 3 Code Smells

98.9% 98.9% Coverage
0.0% 0.0% Duplication

@bdelacretaz bdelacretaz merged commit 9a99ba5 into master Jun 24, 2021
}
super.remove(key);
suppliers.remove(key);
return null;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bdelacretaz I think you meant to return super.remove(key) here if computeValueOnRemove is true. How about this?

Supplier<T> supplier = suppliers.remove(key);
if (supplier != null) {
    super.remove(key); // this should be unnecessary, otherwise I believe it would be a bug?!
    return computeValueOnRemove ? supplier.get() : null;
} else {
    return super.remove(key);    
}

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, both the tests and the code were wrong!

Good idea to use the Supplier in this way, I have committed a slightly different fix that sets the Stats and that always returns null unless computeValueOnRemove is set - I think that's less confusing. 4cce079

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 looks good to me

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants