You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a user, it would be nice if the metadata used through the SDV ecosystem was the same. For some tools, constraints are irrelevant and so having them in the metadata is confusing.
In order to make metadata consistent throughout our ecosystem, we want to separate constraints from it.
Acceptance criteria
Move all functionality involving constraints in the metadata into the BaseSynthesizer class. This includes
Instead of add_constraint, create a new add_constraints method
Parameters
constraints - List of constraints described as dicts in the following format: {'constraint_class': NAME, 'constraint_parameters': {'param_1': ..., 'param_2': ...}}
Error Handling: Perform the same validation & error handling that we are already doing. Note that we always have access to the metadata because it is required when instantiating the synthesizer.
If the user has already fit the synthesizer, warn them that they need to refit it. Warning: For these constraints to take effect, please refit the synthesizer using 'fit'
If called multiple times, continue to add to the existing list of constraints.
On top of moving the constraint logic to the BaseSynthesizer there are some other key changes. The new method for adding constraints take in a list instead of an individual constraint dictionary. Additionally, the format of the constraint dictionary is different as the parameters are now in a nested dict. This means that some logic around the validation code will likely need to change.
The metadata_upgrader will no longer need to update constraints. The code for converting constraints can stay but remove the conversion from convert_metadata
The text was updated successfully, but these errors were encountered:
Problem Description
As a user, it would be nice if the metadata used through the
SDV
ecosystem was the same. For some tools, constraints are irrelevant and so having them in the metadata is confusing.In order to make metadata consistent throughout our ecosystem, we want to separate constraints from it.
Acceptance criteria
BaseSynthesizer
class. This includesadd_constraint
, create a newadd_constraints
methodconstraints
- List of constraints described as dicts in the following format:{'constraint_class': NAME, 'constraint_parameters': {'param_1': ..., 'param_2': ...}}
Warning: For these constraints to take effect, please refit the synthesizer using 'fit'
Expected behavior
Additional context
BaseSynthesizer
there are some other key changes. The new method for adding constraints take in a list instead of an individual constraint dictionary. Additionally, the format of the constraint dictionary is different as the parameters are now in a nested dict. This means that some logic around the validation code will likely need to change.metadata_upgrader
will no longer need to update constraints. The code for converting constraints can stay but remove the conversion fromconvert_metadata
The text was updated successfully, but these errors were encountered: