location data quick fix

[czue]

So the location_data property is actually a dict which was causing DET's --location and --with-organization flags to crash for any location that actually had any custom properties set.

This quick fix just serializes it to a string going into the DB allows the import to (mostly) succeed (also needs dimagi/commcare-hq#27831).

Longer term I think we would want to either:

1. (easier) Convert this to a JSON column in the DB (at least for postgres)
2. (better) "Flatten" the dict, by creating a separate column for each possible field value inside the location_data dict.

@solleks one observation is that DET appears to be adding an "id" property to the dict. Is this expected and do you have a suggested way of handling it? I just left it for now.

[czue]

this is an example of the id property that gets injected

[solleks]

It was a surprise to me, but the 'id' comes from this line:
https://github.com/dimagi/commcare-export/blob/master/commcare_export/env.py#L203

It seems to be recording the path to the dictionary within its enclosing object. I would leave it as is for now because I don't know how to avoid it for location_data without affecting its intended use.

[czue]

thanks for chasing this down!

[solleks]

Thanks for fixing this bug.

One problem for the solution of flattening the dict is that the possible properties of location_data may not be discoverable before reading the actual locations and minilinq doesn't seem to offer a mechanism to dynamically create a new output column as properties are discovered.

A json type column does seem like a good fit, though. And hopefully that wouldn't be much work to implement.