I’m starting to look into enabling Iniz to provide a way to extract existing concepts as a ready-to-use CSV file. In fact this will lead to being able to do that with any metadata but let’s start with the elephant in the room.
I would envision a GET REST endpoint whose payload will be the CSV file basically. Any semantics preferences?
I might suggest that the cleaner semantics here is to provide a mapping based on the requested format, e.g.,
GET /openmrs/ws/rest/v1/concepts?q=...
With either the Accept header set to text/csv or text/iniz+csv or the same setting through, e.g., a format query parameter. After all, the resource being requested isn’t per se different, it’s just a different representation of it.
I realise this is probably a little tricker to implement though.
What @ibacher suggests makes a lot of sense to me. Would be great to see this functionality added for all domains, and to do so in a way that enhances the capabilities of existing REST endpoints for getting metadata via different representations.
However I was just starting to think that my idea wasn’t so good for the reason that each domain would require a new REST endpoint to be defined. And that doesn’t scale too well.
Whereas this kind of stuff would:
GET /openmrs/ws/rest/v1/csvexport?domain=concepts&...
fyi @bistenes… (I know that Brandon has already done some work on building scripts to export concepts into CSV format that we may be able to leverage).
Thanks for the ping @mogoodrich. Yes, I implemented a concept CSV exporter in Python. I think it works pretty nicely. It’s in GitHub under Iniz Exporters. It might serve well as a reference implementation if you decide to implement in Java.
Just to give some insight at my POC so far. First I was hoping to use Jackson CSV data formatting tool, however there are limitations with the CSV serializer that do not exist with the core JSON one. It’s being addressed but in the meantime I’m attempting the following approach:
Fetch from API
→ serialize as Map<String, Object> → add + transform + remove entries and end up with a Map<String, String> → make a CSV out of the map
Clearly the middle step is the key and complicated one. That’s for instance where any value in the map that extends BaseOpenmrsMetadata is flattened into something like its UUID or its name ; or where a collection of such metadata is flattened into a ";"-separated list of UUIDs or names.
That’s also where concept names have to be handled, that’s quite a special case within Iniz.