- Mar 08, 2017
-
-
gmantele authored
This issue has been raised with an H2 database.
-
- Mar 02, 2017
-
-
gmantele authored
-
- Mar 01, 2017
-
-
gmantele authored
-
- Feb 24, 2017
-
-
Ole Streicher authored
This import can not be resolved in a standalone version of adql. It also creates a circular dependency: ADQL then depends on TAP, which depends on starjava, but starjava depends on ADQL.
-
- Feb 23, 2017
-
-
gmantele authored
ResultSetTableIterator (i.e. functions returning unknown numeric values were not set with the right datatype but char* instead).
-
- Feb 22, 2017
- Feb 20, 2017
-
-
gmantele authored
-
- Feb 09, 2017
- Feb 01, 2017
-
-
gmantele authored
Date and Time are converted into a string with the following resp. formats: 'yyyy-MM-dd' and 'HH:mm:ss'.
-
- Oct 12, 2016
-
-
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().
-
- Sep 14, 2016
-
-
gmantele authored
job as been interrupted not by a TimeOut (cf executionDuration) but by an IOException.
-
gmantele authored
47d36bfb In the UWS and TAP configuration files the executionDuration has to be provided into milliseconds. But the UWS parameter MUST be in seconds. So now, UWS is still keeping this duration in seconds (in its ExecutionDurationController) but TAP keeps it in milliseconds (in order to avoid unexpected silent modification of the API) and converts it into seconds for its controller (i.e. TAPExecutionDurationController), for the default home page and for the Capabilities page.
-
- Sep 13, 2016
-
-
gmantele authored
68666ccb It happens that the JDBC driver returned an Integer instead of a Short for a Postgres SMALLINT column. This is not a problem for all formats because of implicit cast, except for FITS which requires an exact correct type. This commit ensure that columns declared as SMALLINT in the metadata are always casted as Short.
-
- Sep 09, 2016
-
- Sep 02, 2016
-
-
gmantele authored
If a BOOLEAN database column is encountered, its datatype will be considered as SMALLINT (because TAP 1.0 does not support BOOLEAN) and its values will be converted into 0 for FALSE and 1 for TRUE. This last part was missing in the TAP library before this commit.
-
- Sep 01, 2016
-
-
gmantele authored
This is very helpful if TAP_SCHEMA (or some of its tables and their columns) has a different name in the database. The mapping can be specified to JDBCConnection or directly in the configuration file.
-
- Aug 10, 2016
-
-
gmantele authored
This is particularly annoying for numeric functions like sqrt(...) (example query: SELECT TOP 1 sqrt(2) as s2 FROM whatever_table). This bug has been raised by M. Taylor.
-
- Aug 08, 2016
-
-
gmantele authored
Execution duration should be expressed in seconds in this TAP endpoint, but the TAP Library was returning its internal value which is expressed in milliseconds.
-
- Jul 21, 2016
-
-
gmantele authored
Schema were still ordered by schema_name instead of schema_index when this latter exists.
-
- Jul 18, 2016
-
-
gmantele authored
-
- Jul 14, 2016
-
-
gmantele authored
TAPTable.copy(...) and TAPColumn.copy(...) use directly the attribute dbName instead using getDBName() ; indeed getDBName() <> dbName. Because of this bug, queries with aliased tables did not work anymore.
-
gmantele authored
These two columns let recommend an order, respectively, for tables in their schema, and columns in their table. In addition of these new columns, "arraysize" has been also added. All these new columns are already supported when creating a TAP_SCHEMA from an XML file.
-
- 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)
-
gmantele authored
column in TAP_SCHEMA. Such names are normalized (without any prefix and without double quotes) when getADQLName() is called, but are returned just trimmed by getRawName(). This latter is just used by TAPMetadata when writing the XML description of all TAP tables.
-
gmantele authored
in DBType.DBDatatype (for UNKNOWN and UNKNOWN_NUMERIC). This reset is performed after each JUnit setting a special custom value (otherwise it prevents other JUnit to run correctly)
-
- Jul 12, 2016
-
-
gmantele authored
clause SELECT.
-
- Jul 01, 2016
-
-
gmantele authored
-
- Jun 16, 2016
- Jun 13, 2016
-
-
gmantele authored
-
- Jun 08, 2016
-
-
theresa dower authored
[ADQL] SqlServerTranslator: bug fix for TOP vs LIMITgrammar. Adding support for math functions, including translations for TRUNCATE and MOD non-standard implementation.
-
- May 25, 2016
-
-
gmantele authored
Before correction, if an ADQlObject (e.g. a function or a sub-query) contains another ADQLObject and that both (i.e. parent and child) are matching in a SimpleReplaceHandler and are asked to be replaced, only the parent seemed to have been replaced. However, the child has been replaced, but in the former instance of the parent ; and so its replacement is not visible in the final query. For instance: if all mathematical functions must be replaced by a dumb UDF named 'foo' in the ADQL query: "SELECT sqrt(abs(81)) FROM myTable" ,the result should be: "SELECT foo(foo(81)) FROM myTable" ,but before this correction it was: "SELECT foo(abs(81)) FROM myTable".
-
- Apr 20, 2016
-
-
gmantele authored
This function was originally static. Since no other classes benefits of this static state, this function is no longer static. This might however raise a small incompatibility for the users of the library which used it.
-