Conversation
|
The null items were removed from the array for a couple of reasons. I addressed both, but would like your feedback on the solutions. 1. addedValues / removedValues are converted to Sets which removes an instance of Null. E.g.let set = new Set([aRole, null, null]);
// set is {aRole, null}I addressed that here: https://github.com/PhrontHQ/mod/blob/feature/relationship-insert-at-index-sparse/data/service/data-service.js#L4762-L4763 Note that 2. The converter explicitly prevented sparse arrays. I changed it to pass them through, but this happens at a pretty low level so I'm concerned that the change will break other relationships. That didn't show up in my testing, but would appreciate your thoughts.That new code is here: https://github.com/PhrontHQ/mod/blob/feature/relationship-insert-at-index-sparse/data/converter/raw-foreign-value-to-object-converter.js#L882-L888 |
| } else { | ||
| //TODO: Is this safe? It was added because, in some cases, you may want to preserve a sparse array. E.g. The | ||
| //array has a fixed length, but not all values are defined | ||
| result.push(value); |
There was a problem hiding this comment.
The place it could impact would be a toMany that doesn't uses an array column, we should check PG service for that use case of an update. It might already be just looping over and ignoring it, but not certain it does.
Another thing we could do, is add this behavior only if the propertyDescriptor involved has isOrdered == true. But making sure holes in arrays passed to the PG service are ignored when an array column is not involved brings peace of mind and resilience in the face of a mapping / modeling inconsistency
This PR works with PhrontHQ/postgre-s-q-l.mod#7
It is intended to add 2 features.