BUG: column order should have no effect

[bsipocz]

While I was fixing #445 I noticed that the code picked the first column that matched the criteria (e.g. it did matter where I added the extra info in the test data).
However, the column order should have no effect, e.g. we should parse all and raise an exception if there are multiple columns matching or have a better hierarchy for what to look for.

I'm opening this issue to make sure we double check all service types for this type of hidden regression/assumption.

[msdemlei]

Interesting point. I'll mention that I don't think any IVOA standard actually explicitly says what a client ought to do in the presence of multiple identified things. Outside of ancient SIA, the thing designated for "unique" (in whatever sense) selection (so far; MIVOT might change that) is the utype, so I've made a quick census of where utype is mentioned in pyvo. The nontrivial occurrences:

• dal.adhoc: uses utype to build lists and hence is unconcerned by this issue.

• dal.query: fieldname_with_utype/getbyutype has exactly the greedy behaviour you would like to do away with. getdataurl is a piece of wild heuristics that doesn't count wrt your concerns I'd say -- we cannot forbid multiple matches for these heuristics.

• dal.sla, dal.ssa: use getbyutype

That's about it.

So... if we're serious about failing for non-unique matches, dal.query.DALResults.field_name_with_utype would be the place to do it.

Me... well, I'm not opposed to a reasonable failure mode (warning?), because it's probably cheap and it helps improving services. However, in general I think this kind of validation is the job of, well, validators, and I'd like pyVO to keep defaulting to best-effort operation (i.e., if we can halfway confidently figure out what the service authors wanted us to do, we should do it).

Meaning: I'll kindly review a PR, but I'll not prepare one myself.