Last week I posted my experiences with the MySQL pipe, and if you are try to use the pipe it might be worth a read …
At the end I said that I had reported the fact that the Update pipe did not work, and I thank @Tim and @Moe for pitching in to help.
In the end I succeeded in getting the Pipe to work, but only by modifying a lot of the settings and ignoring parts of the manual. If you are planning or trying to use this Pipe it may be worth a read so that you don’t have to put in the hours I did.
I finally have this working using the original Update Pipe - but only after I have made some substantial changes to the Pipe as shipped AND ignored some of the info that is given on the Pipe help page .
Basically the concept that was used in the Pipe, as shipped and in the help page, describe Updates that are created using a {recordData} field which is a combination of field and value. This is a flawed idea in two ways - firstly it doesn’t work at all, and secondly because its not ever going to give the felxibility we’d need to develop an App.
If you think about a record update, you can target the Database and the field with custom field values that are fixed for each run. But the Index row that you are targetting and the data value you are passing are likely to be record variables. Therefore a combined {recordData} field that has both target field and value will need to be preprocessed at runtime somehow for the {recordData} to hold anything useful… for example you might have to create a new formula field to concatenate the text needed to create the {recordData} string. This is not a great approach.
What I did was to separate out the fieldName and fieldValue into (at least) two new Parameter fields, and changed the Request to reflect that (see below).
What I also realised is that Numeric Value fields need to presented differently to TextValue fields, and so I have a Pipe that passes both a field/numeric pair and field/txt pair at same time. (NB: sometimes the Pipe runs if only one of the field/value pairs in present, but always include a numeric field).
I created new Parameters fieldName1, fieldName2,numValue1,txtValue2
and editde the Request Data part from {{recordData}} to {“{fieldName1}”:{numValue1}, “{fieldName2}”:“{txtValue2}”}
It works and I am happy. But I now realise that some of the other Pipes in this MySQL set are suboptimal too. For example the ‘Filter’ pipes use a Parameter called ‘filter’. This value for filter is actually made up of 3 descrete elements that are even listed in the help page - filterField,filterOperator,filteredValue Combining these into a single field called {filter} does not seem right, and it would be better to have each of these as Parameter in their own right.
That would mean … “action” : “/records/{tableName}?filter={filter}”
Becomes … … “action” : “/records/{tableName}?filter={filterField},{filterOperator},{filteredValue}”
I hope that this is clear and helps you too.