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

HV-1831 Unfinished experiments #1157

Open
wants to merge 5 commits into
base: 6.2
Choose a base branch
from

Conversation

gsmet
Copy link
Member

@gsmet gsmet commented Feb 24, 2021

This is a very rough experiment based on the 6.2 branch. It's not finished at all and I have no idea if we can make it work in the end.

@gsmet gsmet force-pushed the HV-1831-experiments-6.2 branch 2 times, most recently from 0107720 to 51b94c5 Compare February 25, 2021 10:29
if ( !executableMetaData.isPresent() ) {
// the method is unconstrained so there's no need to worry about the tracking
return false;
}

return !executableMetaData.get().getValidatableParametersMetaData().hasCascadables();
return processedBeansTrackingStrategy.isEnabledForReturnValue( executable,
Copy link

Choose a reason for hiding this comment

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

Should the above line be:

return processedBeansTrackingStrategy.isEnabledForParameters( executable,
?

Copy link
Member Author

Choose a reason for hiding this comment

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

You're absolutely right, I copy/pasted things a bit too fast.

processedPaths = new HashSet<>();
processedPathsPerBean.put( bean, processedPaths );
processedPaths = new ArrayList<>();
processedPathsPerBean.put( processedBean, processedPaths );
}

processedPaths.add( PathImpl.createCopy( path ) );
Copy link

Choose a reason for hiding this comment

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

While debugging ProcessedBeansTrackingCycles1Test, I see that ValidatorImpl#validateConstraintsForDefaultGroup executes this code (in #markCurrentBeanAsProcessedForCurrentPath) twice for the same Parent bean ; first time for Parent.class, and second time for Object.class. Both times #markCurrentBeanAsProcessedForCurrentPath is called with the same Parent bean and the same PathImpl object as arguments.

Since processedPaths is an ArrayList<PathImpl>, it contains 2 copies of the same PathImpl. Was this intended?

I see that processedPaths was changed from a Set<PathImpl> to an ArrayList<PathImpl>, so before this change, (I think) there would have been just one PathImpl in Set.

I don't know if this is a real problem; it's just something I noticed.

Copy link
Member Author

Choose a reason for hiding this comment

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

Hmmm. That's unfortunate. It was part of another experiment and shouldn't have been committed with this one.

How do you want us to proceed? Should I fix things and force push? Or we fix it later? Basically, everything in this class should be reverted, except for the change of meaning of the boolean.

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.

2 participants