Fix problems when setting values on child elements in primitive arrays #1302
Conversation
When checking the existing slices on a primitive array, the slice names are on the objects within the underscore-prefixed array.
Primitive arrays are represented with two arrays: one that stores the primitive values, and one that stores child elements. When creating an element at a given index in one array, also create an element at the same index in the other. Slice names at a given index should be equal. When resoving soft indices under manual slice ordering, treat "no slice name" as its own group of slices. This helps guarantee correct array indices when assigning child properties of a primitive array.
In places where code coverage reported uncovered code, add tests where possible. Some uncovered code represented logically impossible scenarios, so that code is removed.
|
In the full regression set, I've discovered some problems with handling caret rules on a |
A primitive array may start out containing some elements, such as when working with ElementDefinition.type.profile. Fill up the array so that each half is the same size.
|
I've made some updates that resolve problems that occurred when assigning extensions on |
Guarantees about not accessing named slices without the slice name only apply when soft indexing is used. The resulting numeric indices, therefore, may be spaced out in order to account for the presence of named slices.
There was a problem hiding this comment.
Is it complicated? Yup. Is it working? Yup. Is it working well? For sure!
I just tried this with the original examples from CIMPL-1116, and wow -- they were messed up before; but now they are perfect. This is a good change and I'm glad to get those pretty nasty bugs out of the way. Thanks, @mint-thompson!
Completes task CIMPL-1116.
Child elements of primitives are represented in JSON by using the name of the primitive element prefixed with an underscore. When the primitive element is also an array, create both the regular and underscore-prefixed arrays at the same time. When adding an element to one array, add a corresponding element to the other. Both arrays track slice names for sliced arrays. While this will sometimes result in the creation of arrays that contain no meaningful elements, these arrays are already cleaned up during export.
This PR changes the way soft index resolution works with
manualSliceOrderingenabled to make it more accurately fulfill the requirement of "no access to elements with slice names without using the slice name." As a result, while the index values returned fromconvertSoftIndicesStricthave changed, the resulting instances are the same. A similar change is made increateUsefulSlices, which is used whenmanualSliceOrderingis enabled.The useful outcomes of this PR are:
valuechild is required on a defined slice, but not required in general.As there are a lot of potential paths through the new code depending on the order in which primitive elements and their children are assigned, I tried to write tests as well as I could to achieve code coverage. Additionally, there were some places in my initial implementation where code coverage was logically impossible, and the unreachable code was removed. In particular, there are places in
createUsefulSlicesandsetPropertyOnInstancewhere I think it is logically impossible to reach the code whensliceNameis not null. Therefore, these code blocks do not attempt to usesliceName. I would appreciate a careful review of these sections in particular.No changes appeared in the partial regression set. I'm going to be running a full regression tonight, and I will post the results in this thread.