- Feb 22, 2017
-
-
gmantele authored
the automatic datatype detection was missing for CENTROID functions. -- Additionally, some JUnit test files of the `adql` package has been moved to the correct location.
-
- Feb 20, 2017
-
-
gmantele authored
-
- Oct 12, 2016
-
-
gmantele authored
-
- Jul 13, 2016
-
-
gmantele authored
sub-query. Without this information, it was impossible to resolve columns makingreference to sub-queries of the clause FROM. See the JUnit test case for a concrete example. (error raised by Hendrik Heinl - ARI/GAVO)
-
- Mar 17, 2016
-
-
gmantele authored
deals with NATURAL JOINs and JOINs using the keyword USING so that being supported by SQL Server. Basically, they are translated as a list of ON conditions. Warning: This translator is just guaranteed to solve the NATURAL and USING issue. Support for datatypes conversion and case sensitivity has to be reviewed. Besides no geometrical function is translated for SQL Server.
-
gmantele authored
in first position. This should be totally harmless and should be conform to the behaviour of a NATURAL or USING keywords in DBMS.
-
- Mar 04, 2016
-
-
gmantele authored
This is easily possible for concatenations, string constants and User Defined Functions having a FunctionDef. A new special datatype was needed for numeric functions and operations: UNKNOWN_NUMERIC. This special type can not be set with FunctionDef.parse(...) and it behaves exactly like the type UNKNOWN, except that DBType.isNumeric() returns true (as .isUnknown()). Thus, while writing the metadata of a result in TAP, nothing changes: an UNKNOWN_NUMERIC type will be processed similarly as an UNKNOWN type: to use the type returned from the database ResultSet or to set VARCHAR. (no modification of TAP was needed for that)
-
gmantele authored
(indeed, a Concatenation object has no name).
-
- Jan 29, 2016
-
-
gmantele authored
-
- Sep 01, 2015
-
-
gmantele authored
types. The notion of "unknown type" is different in function of the target object: - a DBType and a FunctionDef have an unknown type if their function isUnknown() returns true. In such case, the other functions such as isNumeric/String/Geometry() will return false. - an ADQLOperand (e.g. ADQLColumn) does NOT have a isUnknown() function. But if the type of the operand is unknown, its functions isNumeric(), isString() and isGeometry() must ALL return true. Otherwise, just one of these functions can return true.
-
- Jun 16, 2015
-
-
gmantele authored
-
- Jun 09, 2015
-
-
gmantele authored
-
- Jun 08, 2015
-
-
gmantele authored
-
- May 04, 2015
-
-
gmantele authored
[ADQL] Rename UnresolvedJoin and UnresolvedFunction so that normalizing all UnresolvedXxx exceptions.
-
- Apr 22, 2015
-
-
gmantele authored
-
- Feb 11, 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).
-
- Sep 25, 2014
-
-
gmantele authored
-
- Aug 20, 2014
-
-
gmantele authored
-
- May 28, 2014
-
-
gmantele authored
ADQLObject has now a new function: getPosition(). To allow it, the parser and all ADQL query tree item have been modified to define this function properly. The parser is setting this position for all parsed items. The test class/main function "TestGetPositionInAllADQLObject" aims to check that after a parsing all items really have a defined position.
-
- Apr 10, 2014
- Apr 09, 2014
-
-
gmantele authored
ADQL: Correct version number for all modified ADQL related classes since the official v1.1 release. Now, version number after any modification in ADQL is v1.2.
-
gmantele authored
ADQL: Fix an ADQL bug (raised by Dave Morris) in the management of subqueries: before, it was impossible to use (in a clause different from the FROM) columns of a father query inside a subquery.
-
- Apr 04, 2014
-
-
gmantele authored
ADQL: Completely change/improve Joins management, and particularly NATURAL JOIN and USING JOIN. Now, every joined columns are represented by a DBCommonColumn instance which has a given table coverage. Before, there was a problem while using at least 3 or 4 NATURAL JOINs. Bug raised by Menelaos Perdikeas (ESAC).
-
- Apr 03, 2014