FOCUS_Spec
FOCUS_Spec copied to clipboard
Add a indication of mutability to the content contraints of each column
Description
For the processors of FOCUS data, the ability to know which columns are mutable or immutable and thus "safe" to use as a canonical reference or property of the line item is a critical guide to how the data can be safely used downstream in reporting, analysis, etc...
For example, consider the two columns "BillingAccountId" and "BillingAccountName" the account ID is likely (and should be!) a immutable field that does not and can not change and is set by the provider, whereas the account name is set by the practitioner_ and can and likely will change, at the whim of the practitioner to suit their own business requirements.
Proposed approach
Add a new constraint to the "Content Constraints" called mutable with a required value of either true or false
Context
Raised during recent review of the spec during the ad-hoc review call on March 4th at 12:00 EST
Reducing the scope of this to only the smallest possible set of columns that should be defined as immutable, I think the v1.0 list would be:
- BillingAccountId : Immutable
- SubAccountId : Immutable
This implies that we would explicitly define the name fields for these as mutable and implicitly define all other fields as mutable as well:
- BillingAccountName : Mutable
- SubAccountName : Mutable
- Everything else : Mutable
For v1.1 and beyond, I would suggest we open a separate ticket and then discuss when the time is right if we should also make the following immutable:
- ResourceId
- SubAccountId
- SKUPriceId
- SKUId
- CommitmentDiscountId
@silvexis Could you please make the PR to add the appropriate language to the spec and then drive the discussion at one of the TF meetings? Thanks
This is a situation that is seen is provider data all the time and the practitioners have to be able to reflect the immutable columns after the change.
Few pointers : Ideally most ID's coming from the provider should be mutable anyways. ( are there any exceptions to this?) -- If they are not we should discuss and based on discussion , open a PR. -- If they are all mutable and we have no exceptions, we should maybe put a standard statement rather than defining each column as mutable or not.
support carried over to #1043