Let me see if I can ask this question coherently, because it is a potentially complicated condition.
Trying to evaluate whether the products stock by attribute table is properly populated for a given product. Already have seen in the forum that when working with more than one attribute for the product that some have either properly or improperly added a product variant to the table with only one attribute tracked (or at least a number of attributes less than the full quantity available).
The question comes to what constitutes the products with attributes stock table being properly populated? (Correct number of attributes included in the combination of attributes.). For example if a product has three attributes, is it acceptable for only two to be considered for stock tracking purposes/existing functionality of the module. What conditions should automatically be considered as non-attributes to consider (ie read only only?)?
It's already evident that there are insufficient means of tracking if an attribute has been "turned off" from being important for stock tracking purposes as this would require an additional table to address properly/sufficiently (attribute when associated with a specific product is not to be considered). Sure it could be stuffed into a field of an existing table; however, that violates normalization principles of databases. (Yes I know that there are more than likely cases in the ZC default coding that also don't follow strict normalization, in fact this plugin doesn't either, but...)
Ideally, once a product is populated with it's stock attributes, the number of attributes to consider won't change, but I'm also trying to address "knowing" that there are not discrepancies in the database population. For example if a product is originally populated with three types of attributes, and then in the future one of those is removed, what also removes that attribute tracking from the database, the user only? If the same product having three attributes, has an additional attribute added to it, what happens and does that too need to be adjusted?
The way I was considering approaching the product is out-of-stock (needing to be made inactive) was to look at the maximum number of attributes being tracked and if the results from the database containing that number of attributes for the product indicated no available quantity when searched on the value of one of the tracked attributes, then to disable the product. Currently it disables the product if there is no quantity returned when there is no quantity for the combination of the attribute and I think it is/was all of it's siblings of that one attribute joined together. Ie, expecting that every possible attribute value of the product is considered for tracking the exhaustion of the product.
Bookmarks