You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order to make getting data from a REST API easier,
a result of a SELECT could be mapped to the data from REST API in this way:
-in data.csv -sql "SELECT someId, someValue FROM ..." -map:rest="http://.../{someId}/{someValue}"
Each row of the SELECT result would form an URL using the template from -restJoin,
and the result would be added to a new table.
Alternatively:
This would need quite a few parameters on:
how to create the request (HTTP method, url, headers, ...)
how to parse the response (format, items location, ...),
how to to create the output (name, format, json format, ...)
and so on.
Some of these parameters are already implemented for -in and -out.
Therefore, it may be smarter to keep CsvCruncher a bit simpler, RISC-like, and instead, implement the REST-mapping as an alternative of -sql:
In order to make getting data from a REST API easier,
a result of a SELECT could be mapped to the data from REST API in this way:
Each row of the SELECT result would form an URL using the template from
-restJoin
,and the result would be added to a new table.
Alternatively:
This would need quite a few parameters on:
and so on.
Some of these parameters are already implemented for
-in
and-out
.Therefore, it may be smarter to keep CsvCruncher a bit simpler, RISC-like, and instead, implement the REST-mapping as an alternative of
-sql
:-in singleImport.csv -out mappedData.csv -map:rest="http://..."
Assuming there would be just a single input.
This would basically be just a limitation on supported use cases.
The mapping could perhaps be done using the Java-based SQL functions, which would
but this seems quite cumbersome way to do it.
The text was updated successfully, but these errors were encountered: