We currently read CSV files as pipeline config; internally these are read and generate an in memory configuration structure as EDN. It would be useful for programatic use cases to be able to target the EDN configuration directly, e.g. from within unit tests etc.
For this feature to result in a super friendly workflow I can imagine a few useful options would be:
To run table2qb on a --column-config CSV file and output its config map to stdout as EDN.
To be able to read an EDN --column-config
In the table2qb API be able to use an EDN value programatically (you can probably do this already) but we should document it & check it's friendly for developer/library style usecases.
1 would allow workflows where a customer can give us a CSV config and we can convert it to an EDN based one for test cases etc
We currently read CSV files as pipeline config; internally these are read and generate an in memory configuration structure as EDN. It would be useful for programatic use cases to be able to target the EDN configuration directly, e.g. from within unit tests etc.
For this feature to result in a super friendly workflow I can imagine a few useful options would be:
--column-config
CSV file and output its config map to stdout as EDN.--column-config
1
would allow workflows where a customer can give us a CSV config and we can convert it to an EDN based one for test cases etc