Write form path in Answers

[open-dynaMIX]

The recursive nature of our Forms (in combination with FormQuestions) often has a negative impact on performance and developer sanity. One of many examples can be seen in this commit.

To simplify things, we want to write the form path to the Answers, i.e. the path from the case to the form the Answer actually belongs to.

This will be null, if there is no FormQuestion involved.

This is a prerequisite for #460.

[czosel]

/cc @sliverc

[open-dynaMIX]

/cc @winged

[sliverc]

@open-dynaMIX
I don't quite see how this helps with issue #460 because answers are flat only questions are nested. Exceptions are tables but it won't make a lot of sense to sort cases by table data.

Maybe I am missing a recent change but could you outline a specific use case where this form path would help?

[open-dynaMIX]

Hey @sliverc 👋!

In the context of #460:

As questions can be used in multiple forms and answers are flat, it's difficult to filter the answers for the ones answering a question in a specific form.

Right now we tavel the path to make sure we only fetch the right answers. This can be seen here. This works, but has a potential for performance issues and is hard to maintain.

The filter expects a path (e.g. form1-slug.form2-slug.question-slug). If this path (without the question-slug) would be saved in the answer, we could just filter the answers for that, instead of checking every level.

@winged was talking about another usecase in the JEXL-evaluation. I can't say anything about that, as I have never touched this.

[sliverc]

@open-dynaMIX
One design decision was (I assume this hasn't changed when I look at the schema) that a question is the same no matter what form it is on.
This means if a question is referenced multiple times it can only have one answer per document resp. case.

So in a filter it doesn't make sense to define the path to a question but simply the question-slug will do and an answer. This should make things easier and this issue obsolete.

Does this make sense or am I overlooking something?

[sliverc]

Just saw that there is a SaveDocumentFormAnswer mutation. That got introduced later on as it seems and makes things more complicated. I have a feeling this needs to be rethought as I do not see a need for it and it undermines the design decision one question, one meaning and ends up in issue like you have here now.

I do not have the full picture but those are just some thoughts to potentially think about.

[czosel]

@sliverc If you have time, let's have a short call about it 😉

[winged]

One design decision was (I assume this hasn't changed when I look at the schema) that a question is the same no matter what form it is on.

This is still true, and won't change either.

This means if a question is referenced multiple times it can only have one answer per document resp. case.

We have subdocuments; and a question may in fact be asked in multiple contexts across the document tree. For this reason it's important that we can define which instance of the question within tree was meant.

Even if we would enforce question uniqueness across a whole form tree, we would still have the case of table questions, where it would break if we have multiple rows.

For this reason I think we won't get around the hierarchical lookup, which is by any means already deeply ingrained by way of how the JEXL expressions work, for example: there, you can also navigate to "parent" documents and check values, which we need for example do determine question visibility. I'd prefer having the same kind of syntax available anywhere, and having the same meaning

[czosel]

(I just sent out an invite for a telco about this for tomorrow, 13:00.)

[open-dynaMIX]

This is resolved with #505.