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().

2463d5fe

job as been interrupted not by a TimeOut (cf executionDuration) but by an
IOException.

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.

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.

c5cba4ba. The cast into a Short object is
absolutely required for the FITS format.

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.

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.

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.

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.

Schema were still ordered by schema_name instead of schema_index when this
latter exists.

Commit following 6fc7f8fd.

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.

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.

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)

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.

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)

clause SELECT.

Add an ADQLTranslator for MS-SQLServer.
(more improvements may later come but this translator already works)

[ADQL] SqlServerTranslator: bug fix for TOP vs LIMITgrammar. Adding support for math functions, including translations for TRUNCATE and MOD non-standard implementation.

Before, the scripts relied unfortunately on the compilation performed by
Eclipse. Now, all the JUnit test cases are compiled all the time before
performing the JUnit validation (i.e. ANT task named `junitValidation`).

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".

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.

Before this commit, unsigned integers were also allowed (as for ORDER BY).

Because of a test of the first parameter (non existing for functions
like PI() and RAND()), a NullPointerException was thrown and so
was stopping brutally an ADQL query interpretation.

See the commit bd621842,
for the first part of the fix (which actually did not really
fixed the problem: connections "idle in transaction" were
still in the database ; the connection being inside an opened transaction,
it generates lock issues in the database in addition of probably taking
some memory resources).

with additional information about dependencies, JUnit and ANT scripts.

The transaction and Statement were closed too early before.
  - Fetching the row was not possible once the first bunch of fetched
rows was over.
  - The problem of "statement is aborted" preventing the re-use of
a same DB connection was apparently still there, but occurred less often.

  Now, any transaction potentially started in a DB connection is always
closed after one of the public functions of JDBCConnection is called ;
except executeQuery(ADQLQuery) whose the call MUST be wrapped inside a
try...catch block in which DBConnection.cancel(true) MUST be called
in case of error (in order to effectively end any started transaction).

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.

in first position. This should be totally harmless and should be conform to
the behaviour of a NATURAL or USING keywords in DBMS.

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)