about TAP_SCHEMA columns `schema_name`, `table_name` and `column_name`
(see tap_schema_requirements.md for more details).

exist anymore.

ADQLParser is now a mix between the former ADQLParserFactory and ADQLParser2xx.
All ADQLParser2xx resulting from the compilation of the JavaCC files are
now named ADQLGrammar2xx and implement the new interface ADQLGrammar. The JavaCC
parsers are no longer used directly. This is the role of ADQLParser to simplify
the parser usage and to allow an easy switch between different grammar versions.

Besides, for more clarity in the class organisation, all generated parser
classes have been moved into the package `adql.parser.grammar`.

(see previous commit).

When defining in the configuration file a different name for TAP_SCHEMA content,
the service implementor was also forced to define the same mapping in the
database with the column `dbName`.

This is no longer necessary. From now on, the `dbName` column will be ignored
for all standard TAP_SCHEMA content. Instead, the name specified in the
configuration file (if any) will be used instead. This way, the mapping for
standard TAP_SCHEMA content is only specified once and at only one place:
the configuration file.

_This commit resolves the GitHub issue #98_

This commit fixes a typo introduced in the commit
09ee79c4 ; because of that the VOTable's COOSYS
was not added anymore in query results.

Now, JDBCConnection is fully capable to test the existence of schemas, tables
and columns of a MySQL database. Thanks to @zonia3000 for solving this issue.

standard table. The same for the additional column
TAP_SCHEMA.columns.coosys_id.

On the contrary to other DBMS, MySQL supports schemas, but as databases.
Which means that JDBCConnection gets from the JDBC driver that MySQL does
not support schemas and so it tries to access TAP_SCHEMA tables with a
'TAP_SCHEMA_' prefix instead of 'TAP_SCHEMA.' one. Since MySQL does
behave like it supports schemas, JDBCConnection.supportsSchema must be
set to 'true' if the DBMS is MySQL.

Besides, since no schemas are returned by the JDBC driver
(cf DatabaseMetadata.listSchema(...)), the function
JDBCConnection.isSchemaExisting(String, DatabaseMetaData) must always assume
that the specified schema exists if the DBMS is MySQL. This is particularly
important when the existence of 'TAP_UPLOAD' must be checked, because if the
function returns 'false' the library will attempt to create the database/schema
'TAP_UPLOAD' and will obviously fail due to a lack of permissions. Of course,
it means that the TAP implementor must create manually the schema/database
'TAP_UPLOAD' him-/her-self.

The second particularity of MySQL is the quote character for identifiers.
It is a back-quote (`) instead of a double quote ("). To reflect this
difference, JDBCTranslator.appendIdentifier(...) has been overwritten in a new
JDBCTranslator extension: MySQLTranslator.

The translation of all SQL types and mathematical functions have been adapted to
MySQL according to the online documentation. Few tests have been done locally
with a tiny database. This seems to work but further testing should be
performed in order to ensure the stability of this implementation.

Now, it is recommended to throw a DBCancelledException from any DBConnection
long processing. It is already done for the upload of a table, the execution
of an ADQL query and the setting of a whole TAP_SCHEMA. The flag
JDBCConnection#cancelled has now a bit different meaning: it is set even if
the Statement.cancel() fails so that any JDBCConnection function can see that
a cancellation has been requested.

Two comments:

- JDBCConnection.getDBMSName(String url) is now deprecated ; it may disappear
  in a next version of the ADQLLibrary.
- In case the DBMS name can not be retrieved (generally because of an
  incomplete JDBC driver implementation), NULL will be returned.

Few useless casts have also been removed.

It is also now recommended to make DBConnection.executeQuery(ADQLQuery)
return NULL if the query has been aborted (indeed, the DBConnection is
the only one that can reliably know that fact). JDBCConnection has been
adapted consequently.

Two embedded DBMS are used: H2 and a little SQLite. JDBC drivers are provided
in the `lib` directory. The databases are created and deleted automatically
by the JUnit tests (see `test/tap/db_testtools/DBTools for more details`).

The ANT and Gradle build scripts have been updated to reflect all these test
modifications.

This issue has been raised with an H2 database.

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.

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

Commit following 6fc7f8fd.

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

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

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

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.

(merge with branch 'unknownFctType')

Such value is replaced by NULL while ingesting it into a Postgres
database.

[TAP] Small fix: the translated SQL query was logged only after the query execution ; so, in case of error,
the SQL query is not logged and can not be checked by service provider.

[UWS,TAP] Errors and log management improvements. Particularly, now TAP and UWS are able to manage correctly HTTP request abortions (i.e. when the user stop the request before the response has been fully sent, or when there is a connection problem or a time-out). Such abortions are considered by UWS and TAP merely as job abortion/cancel. No error is logged any more. In addition of this correction, log entries concerning the execution of a TAP sync/async job have been modified so that having more coherents messages. And stack traces of exception that occurred when executing a job (sync or async, tap or uws) are displayed just once: at the JOB END log entry, and not by the HTTP RESPONSE_SENT entry. And finally, output flush and interruption detection are made more often when writing a query result (the flush is particularly important when combining with fetch-size > 0 in synchronous mode....the sync response is then a streaming output).

[TAP] Add the possibility to set the FetchSize on a DB Statement for the execution of ADQL queries. It is also possible to set a fetchSize different for synchronous and asynchronous queries.