FWD » Core Development » Database

Alexandru Lungu wrote:

• flip operation seems redundant. Instead of or-ing with initialDataBitSet and then flip, please keep the inverted state directly in initialDataBitSet to avoid flipping.

My goal was to store the initial non null values, in case this bitset could be used in the future, but storing null properties bitset, for this issue specifically, works better indeed.

• // if the schema defines any dynamic initializers for this record, set them first is an invariant that is broken now. Before your changes, the static initial values have higher priority. After your changes, dynamic initializers have higher priority. Please make a test to confirm the order is not relevant or otherwise restore the original order of setters.

When it comes to the dynamic initializers, before, they set the values first, then the static initializers ignored the set values, so the dynamic ones had the priority, once set, the dynamic values could not be unset.
Now the static initializers are setting all it's values, then the dynamic ones overwrite the already set (or not) properties, so the dynamic initializers also have the higher priority.

My goal was to store the initial non null values, in case this bitset could be used in the future, but storing null properties bitset, for this issue specifically, works better indeed.

Please apply the change to 9669a.

Now the static initializers are setting all it's values, then the dynamic ones overwrite the already set (or not) properties, so the dynamic initializers also have the higher priority.

Got it, it makes sense!

               nullProps.and(dynamicInitializers[i].getProperties());
               nullProps.andNot(dynamicInitializers[i].getProperties());

Doesn't this make nullProps full of 0? From my understanding:

Please test dynamicInitializers case. I recommend doing different configurations and debug into understanding whether the final nullProp is set right.

Committed a small change to rev 15719.

Considering the nature of the changes, I went ahead with the testing, FwdTests and 2 large customer application unit tests passed.

Please post the test-cases you built for testing 9669a.

As part of 9669a review:

• There is a misalignment of getProperties in regard to the javadoc.
• nullProps = (BitSet) initialDataNullProps.clone(); this won't work. nullProps is sent as a parameter, so the assignment will simply change its reference and it won't propagate the constructed nullProps upstream.
  • Maybe you can build a blank nullProps, do the logic and return it. In the caller, simply assign it to nullProps
• I suppose the or is redundant in the following code
  

              nullProps.or(dynamicInitializers[i].getProperties());
              nullProps.andNot(dynamicInitializers[i].getProperties());

  • Anyway, I think this approach is not completely right because you presume that the dynamicInitializers will always initialize with a non-unknown value. This is not true, the dynamic initializer can do the setting with unknown.

Alexandru Lungu wrote:

• Anyway, I think this approach is not completely right because you presume that the dynamicInitializers will always initialize with a non-unknown value. This is not true, the dynamic initializer can do the setting with unknown.

andNot Clears all of the bits in this BitSet (nullProps) whose corresponding bit is set in the specified BitSet (dyn props).
If the dynamic initializer sets a value, it will be unset in the nullProps, if it does not set it, the corresponding bit in nullProps will remain set.
The truth table for the operation we need is:

nullProps: 0 0 1 1
dynprops:  0 1 0 1
result:    0 0 1 0

Alexandru Lungu wrote:

• Anyway, I think this approach is not completely right because you presume that the dynamicInitializers will always initialize with a non-unknown value. This is not true, the dynamic initializer can do the setting with unknown.

Oh, I think I understood you wrong the first time, you mean that the properties is set even if the supplier of the dynamicInitializers provides a null value. Theoretically, this indeed is an issue with the new changes, though I am not sure if a dynamic initializer can supply a null value. The javadoc states that DynamicInitializer is A helper object which applies the result of an invocation of a dynamic initial value (e.g., "today" for a date, "now" for a datetime[tz]). In my understanding the values should always be non null;

Removed getProperties in rev 15722.

FwdTests passed.

Branch 9669a was merged to trunk as rev.15743 and archived.