gmantele / vollt

Java libraries implementing the IVOA protocol: ADQL, UWS and TAP
http://cdsportal.u-strasbg.fr/taptuto/
29 stars 28 forks source link

Database error message using db_name instead of adql_name #108

Closed gmantele closed 5 years ago

gmantele commented 5 years ago

When the execution (in the DB) of an ADQL query fails, the error message returned by TAP is coming from the database with sometimes real database names of the table/column(s). This is particularly the case with PostgreSQL.

In order to avoid that, table and columns used in an ADQL query should be aliased as much as possible. In such case, it seems that the database (again, really observed with PostgreSQL for the moment), the errors reported by the database use the alias (adql_name) instead of the real name (db_name).

However, this small fix will not work on column names used only in a constraint part ; it will work for table names and SELECTed columns....but still, it is an improvment

gmantele commented 5 years ago

For instance, with the following ADQL query:

SELECT col1, count(col2)      
FROM tableA               
WHERE col2 > 0 
GROUP BY col2 
ORDER BY col2 ASC 

...PostgreSQL throws the following error message:

ERROR: column "realTableA.col1" must appear in the GROUP BY clause or be used
               in an aggregate function

...though no realTableA was used in the ADQL query. This is quite confusing for the user who is obviously not aware that tableA is the ADQL name of the table realTableA.

gmantele commented 5 years ago

Issue aborted

The easy solution proposed in the commit 09fac54 generates a parsing failure when a column was referenced using a qualified table name (e.g. "aSchema"."aTable"."aColumn"). Indeed, in this case, since an alias is automatically set on every table, such column references should be also automatically adapted so that replacing the qualified table name by its automatic alias. Otherwise, the SQL query can not properly run.

Considering the very low gravity of this GitHub issue and the complexity (as well as its possible side effects) of the solution to implement to properly support all cases, it is for the moment more wise to abort the resolution of this issue.