FOCUS_Spec icon indicating copy to clipboard operation
FOCUS_Spec copied to clipboard

Add a indication of mutability to the content contraints of each column

Open silvexis opened this issue 1 year ago • 3 comments

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

silvexis avatar Mar 04 '24 18:03 silvexis

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 avatar Mar 04 '24 22:03 silvexis

@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

udam-f2 avatar Mar 05 '24 05:03 udam-f2

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.

SonalGarg-SG avatar May 20 '24 13:05 SonalGarg-SG

support carried over to #1043

Matt-Cowsert avatar May 21 '25 00:05 Matt-Cowsert