Thank you Matthew for your attention, for your answer and for the issue you created.
The scenario I can imagine using the .../fields endpoint :
- ask Central for form fields of the form
- the very first time to first create the tables (child table under "repeat" type elements)
- and then each time I check for new data : to detect and create new attributes
- pull data using the $expand=* option filtered by submission date.
- parse / explore the new data json tree to feed the core and child tables.
One advantage I can see is the availability of data types. Actually with central2pg all questions are stored in text fields and I cast it in the type I want in my queries.
But I fear the complexity of the SQL functions to develop in order to explore a big json tree and dispatch it into tables. I will take a look at some complex json_path queries.
My actual set of function is quite simple, really functional and generic. As "child" tables do carry parent ID so it is really simple to transpose data in a relational data model.
So, from a lazy point of view, it would be really easier to be able to filter child tables on submission_date and I will be attentive on the issue you created.
But I am curious so I will try to spend some time this autumn on the approach you suggest.
If another SQL addict want to explore this way, please share it 