IA-4652: Fix looking up instances using JSONLogic with suffixed questions

[beygorghor]

Due to the mobile application's need to assign a type to some calculated questions, the JSONField Instance.json might contain keys with a suffix like this: __int__. This collides with DRF's way to declare accessing sub-objects properties or even casting.

The cleanest solution is to annotate the queryset to give those keys a name not containing __. After the query has been annotated, we can refer to that name and avoid any collisions.

IA-4652

What problem is this PR solving? Explain here in one sentence.

Related JIRA tickets : IA-4652

Self proofreading checklist

• Did I use eslint and ruff formatters?
• Is my code clear enough and well documented?
• Are my typescript files well typed?
• New translations have been added or updated if new strings have been introduced in the frontend
• My migrations file are included
• Are there enough tests?
• Documentation has been included (for new feature)

Doc

Tell us where the doc can be found (docs folder, wiki, in the code...).

Changes

Explain the changes that were made.

The idea is not to list exhaustively all the changes made (GitHub already provides a full diff), but to help the reviewers better understand:

• which specific file changes go together, e.g: when creating a table in the front-end, there usually is a config file that goes with it
• the reasoning behind some changes, e.g: deleted files because they are now redundant
• the behaviour to expect, e.g: tooltip has purple background color because the client likes it so, changed a key in the API response to be consistent with other endpoints

How to test

Explain how to test your PR.

If a specific config is required explain it here: dataset, account, profile, etc.

Print screen / video

Upload here print screens or videos showing the changes.

Notes

Things that the reviewers should know:

• known bugs that are out of the scope of the PR
• other trade-offs that were made
• does the PR depends on a PR in bluesquare-components?
• should the PR be merged into another PR?

Follow the Conventional Commits specification

The merge message of a pull request must follow the Conventional Commits specification.

This convention helps to automatically generate release notes.

Use lowercase for consistency.

Example:

fix: empty instance pop up

Refs: IA-3665

Note that the Jira reference is preceded by a line break.

Both the line break and the Jira reference are entered in the Add an optional extended description… field.

[beygorghor]

Original PR is here

[beygorghor]

Staphan comment:
from my small test, it looks ok.
but from my experience of parquet, you might it problem with key length : duckdb/duckdb-postgres#374 (comment)

  ("iaso_instance"."json" -> 'test__demo__int') AS "testuudemouuint"

apparently there's some black magic at play... it's working but don't know why ;)

OK I think I found out

running the produced sql show warning but execute properly

NOTICE:  identifier "Gestionuudesuuprojetsuuetuusuiviuudes_activitesuuinternesuusuruu5uuderniers_mois_2025_4564654654654654" will be truncated to "Gestionuudesuuprojetsuuetuusuiviuudes_activitesuuinternesuusuru"
NOTICE:  identifier "Gestionuudesuuprojetsuuetuusuiviuudes_activitesuuinternesuusuruu5uuderniers_mois_2025_1234567891011123" will be truncated to "Gestionuudesuuprojetsuuetuusuiviuudes_activitesuuinternesuusuru"

but in fact the UI is just using the json field not that new column
so nothing bad happens

[beygorghor]

@mestachs

but from my experience of parquet, you might it problem with key length

That is a very good point, although, the code replace a character by another one. I.e.: age__int__ (10 chars) becomes ageuuintuu (10 chars)
So we would have had issue with the length of those question names anyway, wouldn't have we?

I thought of naming with indexed aliases like json_alias1, json_alias2, etc. but it required keeping track of an index and it seemed to add unnecessary complexity.

Although, now that I think about it, I wonder if PostGreSQL would complain if we have 2 times the same annotation, like if we said:

{ "and": [
     {"<":  [{"var": "age__int__"}, 6] },  
     {">":  [{"var": "age__int__"}, 2] },  
]}

We might have to use an indexed alias to avoid this situation.

[bramj]

Auwch, this is an annoying one, seems like there's no way around it than the annotate everything like you're doing here.
I didn't properly test, but from the looks of it this looks like it's working.
The iaso/utils/jsonlogic.py has become very complex, almost feels like it should be extracted as a package.

[bramj]

I didn't try it, but for this method, it didn't work to do the annotation right after this line? https://github.com/BLSQ/iaso/blob/fix/IA-4652_suffixed_questions_not_working_in_json_logic_filters/iaso/api/entity.py#L227

[edil3ra]

TOKEN=$(curl -s -X POST 'http://localhost:8081/api/token/'
-H 'Content-Type: application/json'
-d '{"username": "iaso", "password": "iaso"}' | jq -r '.access')

FILTER='{"==": [{"var": "age__int__"}, 25]}'
curl "http://localhost:8081/api/instances/?jsonContent=$(echo -n "$FILTER" | jq -sRr @uri)"
-H "Authorization: Bearer $TOKEN"

FILTER='{"and": [{"==": [{"var": "gender"}, "female"]}, {">": [{"var": "age__int__"}, 30]}]}'
curl "http://localhost:8081/api/instances/?jsonContent=$(echo -n "$FILTER" | jq -sRr @uri)"
-H "Authorization: Bearer $TOKEN"

I have tested those endpoints and got the correct response