wrong error message when output is empty due to filters

[Ansa211]

See query http://hdl.handle.net/11346/PMLTQ-RZTU

There are many nodes matching the query, but the output filters lead to empty output. Thus, the message given, which is Result is empty. No nodes are matching the query. is wrong and rather confusing!

[matyaskopp]

Your query

t-node $t := [
  functor = "ACT"
]
>> $t.functor
>> filter $1 = "PAT"

can be transformed to this query:

t-node $t := [
  functor = "ACT",
  functor = "PAT"
]
>> $t.functor

it has empty result too. functor is a string and = is a string comparison.

[Ansa211]

It still seems confusing to me - when I get the message "No nodes are matching the query", I search for the problem in the query, not in the filters. That is why I think that if there are some nodes matching the query part, but due to the filters, no lines of output are created, a different message should come up.

[matyaskopp]

Now I see where is the problem. The result should not be "No nodes are matching the query" but something like "Empty table" or better "Result is empty."

[Ansa211]

Exactly! Or maybe "Result is empty due to the application of filters". That would clearly indicate that the query itself has some matches.

[matyaskopp]

fixed with https://github.com/ufal/perl-pmltq-web/commit/f8cff491ffa7c3772713de1216d8610e7c826b2e "Result is empty" warning is used when filters are applied

[Ansa211]

I am not sure if this is the intended behaviour, so just to make sure: now when I try to run a query that does not match any nodes and I specify some filters, the message is Result is empty, even though Result is empty. No nodes are matching the query. would be correct and more informative. http://hdl.handle.net/11346/PMLTQ-ZOAO

Of course, there is nothing wrong with the current behaviour. (The full message is given when I click the "w/o Filters" button.)

[matyaskopp]

It is not possible to distinguish where has been size of result reduced to zero. Whole pmltq query(selective and filter part) is translated to one sql query.

[Ansa211]

http://hdl.handle.net/11346/PMLTQ-SPHF with the last line - the sum() function in the filter - the "Result is empty" warning is missing from the output. When the line is commented, the warning is there.

[matyaskopp]

Result is not empty: {results: [[null]]}. Result of this functions SUM/AVG/MIN/MAX/... on empty set in sql is empty value: SELECT SUM(s) FROM (SELECT 1 AS s FROM "a-node" WHERE 1=2) "tbl"; gives

 sum 
-----

(1 row)

I think, that empty field is correct value (example) but it looks like an error. I can replace every null value in table with some other string value undefined/NaN/--/.... What is the best value?

[Ansa211]

When I think about it, the empty string for a null value is fine with me (sometimes, the null comes up where one would expect a string, such as in http://hdl.handle.net/11346/PMLTQ-DHO0).

For me, the source of confusion still is in the fact that there is no way to distinguish between a query giving no nodes and no or empty output coming from the filters. As a user, I would lean towards more informative messages, even at the cost of longer evaluation times. E.g., if the output of the query with filters leads either to "Result is empty" or to a table containing only null values, the query part (without filters) could be evaluated again, until first hit. If there is no hit, the "No nodes are matching the query" would be output; otherwise, either "Result is empty due to filters" or the table with null values would be output. This would lead to a longer evaluation time; however, when I get a "Result is empty" message, or a table with only null values, I often click the "w/o Filters" button anyway to see if the cause is in the query or in the filters.

[matyaskopp]

I understand the reason why you and some user can be confused but currently there is no way to distinguish where the size of result is reduced to zero. If we want to add this feature we have to change translation from PMLTQ to SQL query by adding propagation of number of nodes from the very inner SQL SELECT to outer ones. I have not thought over marginal cases so there should be some problems.

After yesterday's talk with @stranak we decided to replace empty table cell with undef. There should be written some manual page that gives to user an examples and show reasons why the result of query is Result is empty/Result is empty. No nodes are matching the query/undef.

The manual should contain some very simple queries (there should be no doubt where is the size of result reduced to zero), examples:

• http://hdl.handle.net/11346/PMLTQ-BU7V
• http://hdl.handle.net/11346/PMLTQ-CIIF
• http://hdl.handle.net/11346/PMLTQ-XMCP
• http://hdl.handle.net/11346/PMLTQ-Z3YX

TODO:

• [x] replace empty table fields with undef value
• [ ] write short manual with explanation of "no result"