ConstraintAnalysis: add matchCount() or matchesSize()

[ge0ffrey]

But don't add it to the json serialization, as it can be derived from the matches.

Convenience methods for POC building to print to System.out etc.

Also consider, easily finding:

• the constraint weight
• the match weight
• the impact weigh (= constraint weigh * match weight)

Fail fast if matches are null (= not fetched)?

[zepfred]

Fail fast if matches are null (= not fetched)?

We have a flag, analyzeConstraintMatches, that can cause the InnerScoreDirector#getConstraintAnalysis to set matches to null. So, failing fast could potentially cause existing code to break, e.g., SolutionManager#analyze.

[Christopher-Chianelli]

Fail fast if matches are null (= not fetched)?

We have a flag, analyzeConstraintMatches, that can cause the InnerScoreDirector#getConstraintAnalysis to set matches to null. So, failing fast could potentially cause existing code to break, e.g., SolutionManager#analyze.

That depends on where the fail fast is. I think no issue will occur if the fail fast occurs in matchCount() and matchesSize() (provided these new methods are not called).

[zepfred]

Fail fast if matches are null (= not fetched)?

We have a flag, analyzeConstraintMatches, that can cause the InnerScoreDirector#getConstraintAnalysis to set matches to null. So, failing fast could potentially cause existing code to break, e.g., SolutionManager#analyze.

That depends on where the fail fast is. I think no issue will occur if the fail fast occurs in matchCount() and matchesSize() (provided these new methods are not called).

That's correct. @ge0ffrey, did you mean "failing fast" with the new method?

[triceo]

Aren't we just moving the same problem on a lower level now? In order to call matchCount, you need to know if it will or will not throw an exception - and in this case, you don't even have a way to find out.

In my opinion, returning -1 or something like that is a better approach.

[Christopher-Chianelli]

Aren't we just moving the same problem on a lower level now? In order to call matchCount, you need to know if it will or will not throw an exception - and in this case, you don't even have a way to find out.

In my opinion, returning -1 or something like that is a better approach.

I prefer exception compared to returning -1. It suppose to fail hard so users know what to fix. The problem that @zepfred alluded to is SolutionManager.analyze too eagerly fail fasting because matches is null.

[ge0ffrey]

Yes, only scoreAnalysis.matchCount() should throw an exception if matches weren't fetched. SolutionManager.analyse() should still work.

Similarly, ScoreAnalysis.toString() or getSummary() should always work, but it has the top 3 matches per constraint only if matches were fetched.