- Oct 19, 2020
-
-
Grégory Mantelet authored
Fixes #121
-
- Jul 02, 2019
-
-
Grégory Mantelet authored
This commit reverts commit 89418d13. The reverted commit will be applied in another branch (probably 'adql-2.1') as it is part of the next release of ADQL-Lib.
-
- May 10, 2019
-
-
Grégory Mantelet authored
- Now, `ADQLParserFactory.createParser(...)` should be used to create a parser - Only the new function `LOWER` is supported for the moment - Not yet possible to manage the optional features _(next dev to come)_ => 1st step for ADQL-Lib v2.0 - TAP adapted so that using the last stable version of the ADQL language (i.e. 2.0 for the moment) - but not yet possible to set the ADQL version to use in the configuration file
-
- Mar 13, 2019
-
-
Grégory Mantelet authored
This new function - ADQLParser.tryQuickFix(...) - fixes the most common issues with ADQL queries: - replace Unicode confusable characters by their ASCII/UTF-8 version, - double-quote SQL reserved words/terms (e.g. `public`, `year`, `date`), - double-quote ADQL function names used a column name/alias (e.g. `distance`, `min`, `avg`), - double-quote invalid regular identifiers (e.g. `_RAJ2000`, `2mass`). The last point is far from being perfect but should work at least for identifiers starting with a digit or an underscore, or an identifier including one of the following character: `?`, `!`, `$`, `@`, `#`, `{`, `}`, `[`, `]`, `~`, `^` and '`'. It should also been noted that double-quoting a column/table name will make it case-sensitive. Then, it is possible that the query does not pass even after the double-quote operation ; the case would have to be checked by the user. Finally, there is no attempt to fix column and table names (i.e. case sensitivity and/or typos) using tables/columns list/metadata. That could be a possible evolution of this function or an additional feature to implement in the parser.
-
- Mar 21, 2018
- Sep 13, 2017
-
-
gmantele authored
reserved word is encountered instead of a column/table/schema name/alias. On the contrary to the previous commit, this time a list of SQL reserved words has been added into the ADQL grammar. In this way, the parser will ensure that no word of this list is used in an ADQL query. The raised error is then enriched of an HINT message stating that this word is part of SQL, is not supported by ADQL and must be written between double quotes if used as an identifier. The list of SQL reserved words comes from the ADQL-2.0 standard, after removal of all potentially used ADQL words, in order to avoid a conflict with the already existing tokens in the ADQL grammar.
-
gmantele authored
reserved word is encountered instead of a column/table/schema name/alias. No list of ADQL reserved words has been added into the ADQL grammar. However, the ADQL grammar has been slightly changed in order to provide a more precise location of the REAL wrong part of the query. Before this commit, if an ADQL reserved word (e.g. 'point') was encountered outside of its normal syntax (e.g. 'point' no followed by an opening parenthesis), the next token was highlighted instead of this one. Hence a confusing error message. For instance, the following ADQL query: ```sql SELECT point FROM aTable ``` returned the following error message: > Encountered "FROM". Was expecting: "(" Now, it will return the following one: > Encountered "point". Was expecting one of: "*" <QUANTIFIER> "TOP" [...] > (HINT: "point" is a reserved ADQL word. To use it as a column/table/schema name/alias, write it between double quotes.) This error message highlights exactly the source of the problem and even provide to the user a clear explanation of why the query did not parse and how it could be solved.
-
gmantele authored
-
- Sep 11, 2017
-
-
gmantele authored
with a different local charset, the error message will print differently the incorrect character.
-
- Sep 08, 2017
-
-
gmantele authored
when an incorrect character that can not be interpreted by the JavaCC Token Manager is encountered. Actually, the TokenMgrError thrown by JavaCC is caught by all ADQLParser.parseQuery(...) functions, wrapped inside a ParseException which is finally thrown instead of the TokenMgrError. In this way, ADQL-Lib users just have to care about a single Throwable: ParseException. Besides the error message has been slightly modified from: > Lexical error at line 1, column 10. Encountered: "\u00e9" (233), after : \"\" to: > Incorrect character encountered at l.1, c.10: \"\\u00e9\" ('é'), after : \"\" Thus, the error is more user-friendly, more easy to understand by users. Additionally, the incorrect character is displayed, as before, in its unicode expression, but also in its character form (instead of an integer value that nobody can really understand). This commit fixes the GitHub issue #17
-
- Apr 03, 2017
-
-
gmantele authored
a qualified column name should be allowed, but still no column index should be.
-
- Mar 02, 2017
-
-
gmantele authored
-
- Sep 20, 2016
-
-
gmantele authored
The "normal" JOIN: A JOIN B ON A.id = B.id JOIN C ON B.id = C.id is correctly interpreted as: ( (A JOIN B ON A.id = B.id) JOIN C ON B.id = C.id ) But with a NATURAL JOIN, the tree is mirrored: A NATURAL JOIN B NATURAL JOIN C gives: ( A NATURAL JOIN (B NATURAL JOIN C) ) instead of: ( (A NATURAL JOIN B) NATURAL JOIN C ) This is not a problem when the SQL translation is identical to the ADQL expression, but for some DBMS a conversion into a INNER JOIN ON is necessary and in this case we got the following SQL: A JOIN B JOIN C ON A.id = B.id ON B.id = C.id Which seems to work, but is syntactically strange. This commit should fix the generated tree. A "normal" JOIN and a NATURAL JOIN should now have the same form. A JUnit test has been added into TestADQLParser to check that: testJoinTree().
-
- Apr 20, 2016
-
-
gmantele authored
-
- Aug 27, 2015
-
-
gmantele authored
[ADQL] Fix a Big Bug reported by M.Taylor and M.Demleitner: in ORDER BY, GROUP BY and USING only regular and delimited identifiers are accepted, not qualified column names. For instance: "SELECT table.column_name FROM table ORDER BY table.column_name" is wrong. We should instead write: "SELECT table.column_name FROM table ORDER BY column_name". "SELECT table.column_name AS mycol FROM table ORDER BY mycol" is also correct. Of course, for ORDER BY and GROUP BY, it is still possible to reference a column using its index in the SELECT clause. For instance: "SELECT table.column_name FROM table ORDER BY 1".
-
- Jun 16, 2015
-
-
gmantele authored
[ADQL] Fix the ADQL DEBUG mode ; now ADQLParser.setParser(boolean) is doing what it is supposed to do.
-
- Jun 08, 2015
-
-
gmantele authored
-
- Oct 28, 2014
-
-
gmantele authored
[ADQL,TAP] Add STC-S and UDFs support in the ADQL parser. Now, it is possible to provide a list of allowed UDFs, regions and coordinate systems. The ServiceConnection of TAP is now able to provide these lists and to propagate them to the ADQLExecutor. UDFs and allowed regions are now listed automatically in the /capabilities resource of TAP. The type 'geometry' is now fully supported in ADQL. That's why the new function 'isGeometry()' has been added to all ADQLOperand extensions. Now the DBChecker is also able to check roughly types of columns and UDFs (unknown when parsing syntactically a query). The syntax of STC-S regions (expressed in the REGION function) are now checked by DBChecker. However, for the moment, geometries are not serialized in STC-S in the output....but it should be possible in some way in the next commit(s).
-