This issue has been raised with an H2 database.

ResultSetTableIterator (i.e. functions returning unknown numeric values
were not set with the right datatype but char* instead).

Date and Time are converted into a string with the following resp.
formats: 'yyyy-MM-dd' and 'HH:mm:ss'.

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.

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.

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

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

with a constructor having a Properties object loaded with the content
of the current configuration file.

log message (i.e. event = "TABLE_CREATED").

request which has initiated the job creation. Actually the HTTP request is
generated as before, and then, if a job is created, it is set to the ID of the
HTTP request. This modification aims to greatly help the log analysis.

opened by JDBCConnection.executeQuery(...) because a fetch size is set, this
transaction was never closed.

Can be enabled just by providing a file URI in the TAP configuration file using
the property "examples". It is also possible to add manually a TAP resource
whose the returned name must be "examples" like the new TAP resource is doing:
tap.resource.Examples. This latter take a file URI as the TAP configuration
file does. The referenced file must respect the DALI 1.0 or TAP Notes 1.0
syntax. No check of the file is performed by the library ; it is up to the
author of the referenced file (a XHTML/RDFa file) to write a correct "examples"
endpoint content. Check out the examples provided on the GitHub repository in
the directory examples/tap/examples_endpoint.

1) [TAP & UWS] ]MAJOR BUG FIX: The abortion of an SQL query is now correctly
implemented. Before this fix, 2 mistakes prevented this clean abortion:
  a/ The thread was not cancelled because the SQL query execution was
blocking the thread. Then the thread could not treat the interruption though
it was flagged as interrupted.
  b/ The function UWSJob.isStopped() considered the job as stopped because
the interrupted flag was set, even though the thread was still processing
(and the database too). Because of that it returned true and the job phase
was ABORTED though the thread was still running.
  NOW:
  a/ TAPJob calls the function Statement.cancel() (if supported) in order
to cancel the SQL query execution properly inside the database.
  b/ The function UWSJob.isStopped() does not test any more the interrupted flag
and returns true only if the thread is really stopped.
  IN BRIEF: It is now sure that a job in the phase ABORTED is really stopped
(that's to say: thread stopped AND DB query execution stopped).

2) [TAP] BUG FIX: When the writing of a result is abnormaly interrupted for any
reason, the file which was being written is deleted.

by the TAP configuration file in order to add/remove/change some metadata or
to change the output of the TAP resource '/tables'.

function ResultSetTableIterator.nextCol(). The formatting is now performed
in ResultSetTableIterator.formatColValue(Object).

format. A ClassCastException was thrown about an impossible cast from String to
Character.

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.