Always generate an instance for a list with columns other than name and label

Question

Always generate an instance for a list with columns other than name and label

lognaturel opened this issue 3 years ago · 3 comments

Software and hardware versions

All versions

Problem description

It can be useful to have a queriable dataset defined within a form. Because instances are only generated for selects with choice filters, sometimes that requires using a true() filter to force instance creation. If there are columns other than name and label, those are only of value if they're in an instance.

Steps to reproduce the problem

Create a form with a select_one on a list with additional columns but no choice filter
Write a query on that list
See the bizarre Validate error: https://forum.getodk.org/t/referencing-values-in-internal-datasets/36874 (from @jkuester)

Expected behavior

If a list has columns other than name and label, an instance should be generated.

Other information

I'd be in favor of always generating instances: #203
There are weird problems selecting between instances and static selects already anyway: #387
We've proposed something like a new internal-data type #176 but this case is different -- there's a select referencing the list but it doesn't have a choice filter

Answer 1 · 2022-03-04T17:58:09.000Z

@lindsay-stevens you've been in related code recently. Is there a clean way to add this special case? Or do you think we should perhaps move forward on always generating instances? The idea that there might be some client somewhere that doesn't support secondary instances doesn't feel like a compelling reason to keep the extra code path.

Answer 2 · 2022-03-04T19:27:27.000Z

From a quick look I think we'd be adding at at least another if condition around about here in xls2json. Most of the work would probably be in thinking about / checking that this behaves in a reasonable way alongside other overlapping features when the condition is met and not met. To keep a lid on that I'm in favour of always generating instances.

I wonder if the spirit of #203 can apply to #584 i.e. might as well always use itext if select choices are never in the XForm body.

Answer 3 · 2022-04-04T22:55:19.000Z

Closing in favor of #603 which I think we should do sooner than later.

might as well always use itext if select choices are never in the XForm body.

I think that's a bit different because I have seen single-language forms (and written them myself) that use label directly. It's really not as nice to have to use jr:choice-name to get the label through an itext ref and there are existing forms that would break on update.