I have a one-to-many Ontology relationship where -- for a given Alert object-instance -- I want at most one Feedback object-instance for it per User. A Feedback object-instance is Created & Updated by Users using its Add & Modify Actions, respectively (and is used to provide one feedback score & commentary per User per Alert object-instance).
As such, to implement at most one semantics, each Feedback object requires a Primary Key composed of:
feedbackID(PK) =alertID(PK) +userID(PK)
However, in its backend definition, the Feedback object-type's Add Action sets the Primary Key as a UUID, and this cannot be overwritten once instantiated. (Note: An object-reference or property is also possible here, but either would also only be part of the composite key sought). That is to say, although it's possible to synthesize the above composite-key in a frontend Workshop Action Tab (using Workshop variables and forms), it's understandably not possible to overwrite an object's already-existing PK with it.
Indicentally, for completeness, I'll mention, but not necessarily recommend, a two-DataSet option for
composite-key PKconsisting of the following steps:
- The Add Action creates rows for an initial DataSet with
UUID's as itsPK.- A Foundry
data pipelinemirrors this DataSet to create a corresponding DataSet withalertID+userIDas itsPK.- And finally, the Modify Action as well as downstream application uses consume that mirror (second) DataSet.
Again, presented for completeness and not necessarily recommended since it duplicates DataSets, as well as adds propagation delay to the out-of-the-box platform propagation delay.
With that as preamble, is there a just-in-time technique to generate Objects with a composite-key PK consisting of properties from other Objects (again, at Add-Action click time)? I may have missed something. Thank you.
I came up with an interim workaround which broadly include these steps:
Function(snippet below) coupled with aFunction-backed Workshop variablethat returns a count ofFeedbackobjects having the samealertIDanduserIDcombination (i.e. a manually synthesizedcomposite-key):One downside to this approach are lookups against the two columns mentioned, which are neither hashed nor indexed.