Adjust the representation of variants in the database to better accommodate big quantities of variants in a project. Instead of storing variant indices in an array field (with -1 representing the base variant), this change introduces the field "var_type" with possible values "base", "change" and "addition".
"base" represents elements that exist in variants unchanged. These documents gain an additional array field "not_in_var" holding indices of variants in which the element has been removed or changed.
Types "change" and "addition" get an additional field "variant" referencing the given variant index.
Type "change" gets an additional field "changed_fields" referencing the field names which values have changed.
The query generated by get_variants_filter(variants) can be used as mix-in to restrict results to the variant(s) provided. With a single variant as argument the results should not have duplicate element indices, when providing multiple variants possible conflicts need to be handled.
This PR implements the basic element CRUD functions and an updated get_variants_filter.
Bulk-write operations and timeseries functions have not been adjusted.
Changes in "base" elements only propagate to variants if the element in question has not previously been changed in a variant - e.g. if field "foo" is changed in a variant and afterwards the field "bar" is changed in base, then the change to "bar" is missing in the variant. If the element is removed in base instead, it will still exist in the variant.
Adjust the representation of variants in the database to better accommodate big quantities of variants in a project. Instead of storing variant indices in an array field (with -1 representing the base variant), this change introduces the field "var_type" with possible values "base", "change" and "addition".
"base" represents elements that exist in variants unchanged. These documents gain an additional array field "not_in_var" holding indices of variants in which the element has been removed or changed.
Types "change" and "addition" get an additional field "variant" referencing the given variant index.
Type "change" gets an additional field "changed_fields" referencing the field names which values have changed.
The query generated by get_variants_filter(variants) can be used as mix-in to restrict results to the variant(s) provided. With a single variant as argument the results should not have duplicate element indices, when providing multiple variants possible conflicts need to be handled.
This PR implements the basic element CRUD functions and an updated get_variants_filter.
Bulk-write operations and timeseries functions have not been adjusted. Changes in "base" elements only propagate to variants if the element in question has not previously been changed in a variant - e.g. if field "foo" is changed in a variant and afterwards the field "bar" is changed in base, then the change to "bar" is missing in the variant. If the element is removed in base instead, it will still exist in the variant.