FLUID-5133: Implement the inverters/inverse for all existing model transforms and ensure the framework supports invertibility

Description

Currently not all transformations have inverse functions, and it is not certain how well invertibility is supported in the model transformation framework. This needs to be fixed as it's a requirement by the GPII project

Comments

• Justin Obara commented 2015-06-15T10:43:36.279-0400

  @@Kasper Galschiot Markus has this been completed?

• Kasper Galschiot Markus commented 2015-06-15T12:31:11.521-0400

  Nope - this is not done yet, and it will not be finalized in the context of C4A at least... We might be able to make some improvements, but it is a long term thing (requiring 'pockets' and other complex additions to properly support invertibility.

• Kasper Galschiot Markus commented 2016-04-13T08:59:30.619-0400

  Done but needs documentation:

  • fluid.transforms.literalValue: FULLY INVERTIBLE. (the literal value is always independent of the input model, so that will always be left alone).
  • fluid.transforms.value: PARTLY invertable - the 'input' default values are ignored.
  • fluid.transforms.arrayValue: NO INVERSION. Since there is no way of telling whether the value was an array or primitive value before.
  • fluid.transforms.numberToString and fluid.transforms.stringToNumber: PARTLY invertable - suffers from standardTransformFunction issues. Also, if the input is not a valid number (or numberstring), the inversion will be lacky.
  • fluid.transforms.count: NO INVERSION - no way to reproduce the thing we're counting based on knowing the number of entries
  • fluid.transforms.round: LACKY inversion - inverts to identity, since we cannot reproduce the decimal portion of the number based on a decimal. In other words, the decimal precision can not be restored on inversion. Also, suffers from standardTransformFunction issues.
  • fluid.transforms.delete: NO INVERSION - no way to reproduce a deleted element from scratch
  • fluid.transforms.firstValue: NO INVERSION - no way to reproduce an array based on the first element
  • fluid.transforms.linearScale: PARTLY invertible. If `factor` or `offset` are given as paths into the source model (and no default value is provided), we have no way of knowing what they were. Also, if no inputPath is given, we have nowhere to write the inverted result
  • fluid.transforms.binaryOp: NO Inversion: Since we have no way to reproduce the operands based on a result and an operator
  • fluid.transforms.condition: NO Inversion. There is really no half-easy way to know what the original input value was
  • fluid.transforms.arrayToSetMembership and fluid.transforms.setMembershipToArray: Invertable (though with the regular standardTransformFunctions issues). These two will invert to one another.
  • fluid.transforms.arrayToObject and fluid.transforms.objectToArray: Partly Invertable - the two will invert to each other - but there is no guarantee the ordering of the array will be the same on the objectToArray side of things. Also, if the innerValues has lossy transforms, this will obviously affect the overall invertibility.
  • fluid.transforms.indexOf && fluid.transforms.dereference: Inverses of each other. Unable to do proper inversion when "notFound" is provided (and used)
  • fluid.transforms.stringTemplate: NOT invertible
  • fluid.transforms.free: NOT invertible
  • fluid.transforms.valueMapper - partly invertible
  • fluid.transforms.quantize - NOT implemented yet: FLUID-5905
  • fluid.transforms.inRange - NOT impleented yet: FLUID-5905