Project: datamanagement
Issue DM-531: Qserv returns error table instead of error code
Running the tests on pre-loaded data I noticed that for some queries qserv returns result which does not look like it is related in any way to the query - result column names are different from the columns in the query (different in a different way from DM-530). Here is an example of query and result produced: {code} mysql> SELECT sce.filterName, sce.field, sce.camcol, sce.run FROM Science_Ccd_Exposure AS sce WHERE sce.filterName like '%' AND sce.field = 535 AND sce.camcol like '%' AND sce.run = 94; +---------+------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+ | chunkId | code | message | timeStamp | +---------+------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+ | -1 | 0 | NULL | 1.39779e+09 | | -1 | 100 | Dispatch Query. | 1.39779e+09 | | 32767 | 1200 | Query Added: url=xroot://qsmaster@127.0.0.1:1094//q/LSST/1234567890, savePath=/dev/shm/qserv-salnikov-80df10ee4ed55693702f55021486cd45647c3a58ce549e7c826d9626/7_1234567890_0 | 1.39779e+09 | | 32767 | 1300 | Query Written. | 1.39779e+09 | | 32767 | 1400 | Results Read. | 1.39779e+09 | | 32767 | 1500 | Results Merged. | 1.39779e+09 | | 32767 | 1600 | Query Resources Erased. | 1.39779e+09 | | 32767 | 2000 | Query Finalized. | 1.39779e+09 | +---------+------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+ {code} Daniel and Bill explained to me what is happening there - when query results in an error instead of returning mysql error condition (which is an error code plus some text) proxy produces a diagnostic result which is a table (above) containing some info which could be useful to diagnose the issue. This feature looks potentially useful but it may also be confusing for clients like me who are not aware of this feature. For regular mysql client it may be actually harder to intercept errors because one would need to analyze returned table to understand that error condition happened. It may also be ambiguous in a sense that the legitimate query could produce result with the same column names. Like in DM-530 this issue is tied to a question what kind of API we want to provide to qserv clients. If mysql wire-level protocol is going to be our main API then we should probably try to be more mysql-compatible. OTOH if we are going to hide everything behind our own API then we may have more freedom in re-defining what kind of result error condition produces.
Story points: 4