Handling fixed column relationships by specific_combinations and SpecificCombinationTransformer.

[jalr4ever]

Description

I haved added a new SpecificCombinationTransformer, and modifed FixedCombinationTransformer. And a test case for SpecificCombinationTransformer.

Motivation and Context

SpecificCombinationTransformer would transforming when user specified some column-mapping combination, and FixedCombinationTransformer would not running at the same time.

I make FixedCombinationTransformer as default column-mapping combination detector and transformer.As for SpecificCombinationTransformer, it would transforming when user specified some column-mapping combinations, make sure the sample data column-mapping adhere to the specified combinations. At the same time, FixedCombinationTransformer would not run transforming when SpecificCombinationTransformer activated.

How has this been tested?

See test case.

Types of changes

• Maintenance (no change in code, maintain the project's CI, docs, etc.)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.

[Wh1isper]

Do we really need to distinguish between is_been_specified and is_exist_fixed_combinations, seems just for log... Or do you think it would be beneficial downstream?

[jalr4ever]

Do we really need to distinguish between is_been_specified and is_exist_fixed_combinations, seems just for log... Or do you think it would be beneficial downstream?

@Wh1isper Yes we need.

Currently, the consideration is that when the shape of the data does not meet expectations, it can be determined from the logs what caused the lack of transformation; on the other hand, there may be other combinations in the future, and different scenarios may have different logic.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

Attention: Patch coverage is 88.42105% with 11 lines in your changes missing coverage. Please review.

Project coverage is 82.75%. Comparing base (00685a3) to head (3c16c52).
Report is 14 commits behind head on main.

Files with missing lines	Patch %	Lines
.../data_processors/transformers/fixed_combination.py	76.92%	9 Missing ⚠️
...ta_processors/transformers/specific_combination.py	96.42%	2 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #236      +/-   ##
==========================================
+ Coverage   82.17%   82.75%   +0.57%     
==========================================
  Files          84       88       +4     
  Lines        4146     4470     +324     
==========================================
+ Hits         3407     3699     +292     
- Misses        739      771      +32     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Wh1isper]

@jalr4ever Ok and I suggest replace is_exist_fixed_combinations with @property decorator

Like this:

@property
def is_exist_fixed_combinations(self) -> bool:
  return bool(self.is_exist_fixed_combinations)

Then we can reduce the code in fit function, no need tow if blocks but one is enough

[Wh1isper]

LGTM