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
Global: Add version number to subset uniqueness validation #6100
base: develop
Are you sure you want to change the base?
Global: Add version number to subset uniqueness validation #6100
Conversation
This change adds the version number to the validation of unique subsets in the `ValidateSubsetUniqueness` class. Previously, it only checked for overlapping instances based on asset and subset names. Now, it also considers the version number when determining uniqueness. If multiple versions under the same subset are published, a warning is logged and those instances are skipped during validation. This commit improves the accuracy of subset uniqueness validation by including the version number in the check.
Co-authored-by: Jakub Trllo <43494761+iLLiCiTiT@users.noreply.github.com>
For cases, where workfile version sync is disabled, we still need to validate cases where multiple "next version" instances are published under the same subset. The commit adds a info log message instead of warning for instances found without `version` data and continues processing other instances.
Co-authored-by: Roy Nieterau <roy_nieterau@hotmail.com>
Adding a warning message for cases where different versions of the same subset are published under the same asset. This change improves the validation process and provides more informative feedback to users.
# this might happen when workfile version sync is disabled | ||
# we still need to validate cases where multiple "next version" | ||
# instances are published under same subset | ||
self.log.info("Instance found without `version` data: " | ||
"{}".format(instance.name)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will easily produce a cluttered artist facing log for which the artist knows nothing about what to do with this. It's not an actual issue - this is totally valid as far as I know. I would not log this actually. It's not a special case, also the check below in else:
is also completely valid warbubg for the case where multiple instances with matching subset and asset include one that is None
(actually, one might argue that if one has None
and the others do not and their version numbers are higher than the current last version that the behavior is still dangerous and may be considered invalid/erroneous)
# check if asset and subset combination is unique | ||
# just to inform the user with warning about the case | ||
if any([ | ||
asset == a and subset == s | ||
for a, s, _ in instance_per_asset_subset.keys() | ||
]): | ||
self.log.warning( | ||
"Instance found with non unique `asset` and " | ||
"`subset` data: {}".format(instance.name) | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wouldn't do this check in this for loop - it's basically much slower like this because you iterate over all per entry.
key = asset, subset, version | ||
instance_per_asset_subset[key].append(instance) | ||
|
||
non_unique = [] | ||
for (asset, subset), instances in instance_per_asset_subset.items(): | ||
|
||
for key, instances in instance_per_asset_subset.items(): | ||
asset, subset, version = key |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Likely you're better off doing something like:
instances_per_asset_subset[asset, subset].append(instance)
And then:
for (asset, subset), instances in instances_per_asset_subset.items():
if len(instances) < 2:
# All good, ignore
continue
# An instance *may* explicitly set a specific version to publish into
# and if so, it is allowed to publish into the same subset if the versions
# differ between the instances. So we detect whether the instances
# are set to publish to a different version
instances_by_version = defaultdict(list)
for instance in instances:
version = instance.data.get("version")
instances_by_version[version].append(instance)
multiple_instances_per_version = False
for version, version_instances in instances_by_version.items():
if len(version_instances) > 2:
# This is not allowed - multiple instances targeting same version
multiple_instances_per_version = True
non_unique.append(
"{asset} > {subset} > {version}".format(
asset=asset, subset=subset, version=version
)
)
if not multiple_instances_per_version:
versions = ", ".join(str(version) for version in instances_by_version)
self.log.warning(
"Multiple instances are writing to '%s' > '%s' but to different versions. "
"This is allowed but is considered an edge case. "
"The versions to be published are: %s",
asset, subset, versions
)
So that the warning log only shows if there isn't already an error anyway.
Can we address BigRoy's feedback before any testing? |
…t-name-if-multiple-versions
Changelog Description
This changes improves the accuracy of subset uniqueness validation by including the version number in the check.
Additional info
This change adds the version number to the validation of unique subsets in the
ValidateSubsetUniqueness
class. Previously, it only checked for overlapping instances based on asset and subset names. Now, it also considers the version number when determining uniqueness. If multiple versions under the same subset are published, a warning is logged and those instances are skipped during validation.