Class JDBCTranslator

java.lang.Object
adql.translator.JDBCTranslator
All Implemented Interfaces:
ADQLTranslator
Direct Known Subclasses:
MySQLTranslator, PostgreSQLTranslator, SQLServerTranslator

public abstract class JDBCTranslator extends Object implements ADQLTranslator
Implementation of ADQLTranslator which translates ADQL queries in SQL queries.

It is already able to translate all SQL standard features, but lets abstract the translation of all geometrical functions. So, this translator must be extended as PostgreSQLTranslator, PgSphereTranslator, MySQLTranslator and SQLServerTranslator are doing.

Note: Its default implementation of the SQL syntax has been inspired by the PostgreSQL one. However, it should work also with other DBMS, although some translations might be needed (as it is has been done for PostgreSQL about the mathematical functions).

SQL with or without case sensitivity?

In ADQL and in SQL, it is possible to tell the parser to respect the exact case or not of an identifier (schema, table or column name) by surrounding it with double quotes. However ADQL identifiers and SQL ones may be different. In that way, the case sensitivity specified in ADQL on the different identifiers can not be kept in SQL. That's why this translator lets specify a general rule on which types of SQL identifier must be double quoted. This can be done by implementing the abstract function isCaseSensitive(IdentifierField). The functions translating column and table names will call this function in order to surround the identifiers by double quotes or not. So, be careful if you want to override the functions translating columns and tables!

Translation of "SELECT TOP"

The default behavior of this translator is to translate the ADQL "TOP" into the SQL "LIMIT" at the end of the query. This is ok for some DBMS, but not all. So, if your DBMS does not know the "LIMIT" keyword, you should override the function translating the whole query: translate(ADQLQuery). Here is its current implementation:

        StringBuffer sql = new StringBuffer(translate(query.getSelect()));
        sql.append("\nFROM ").append(translate(query.getFrom()));
        if (!query.getWhere().isEmpty())
                sql.append('\n').append(translate(query.getWhere()));
        if (!query.getGroupBy().isEmpty())
                sql.append('\n').append(translate(query.getGroupBy()));
        if (!query.getHaving().isEmpty())
                sql.append('\n').append(translate(query.getHaving()));
        if (!query.getOrderBy().isEmpty())
                sql.append('\n').append(translate(query.getOrderBy()));
        if (query.getSelect().hasLimit())
                sql.append("\nLimit ").append(query.getSelect().getLimit());
        return sql.toString();
 

Translation of ADQL functions

All ADQL functions are by default not translated. Consequently, the SQL translation is actually the ADQL expression. Generally the ADQL expression is generic enough. However some mathematical functions may need to be translated differently. For instance PostgreSQLTranslator is translating differently: LOG, LOG10, RAND and TRUNC.

Note: Geometric regions and types have not been managed here. They stay abstract because it is obviously impossible to have a generic translation and conversion ; it totally depends from the database system.

Translation of "FROM" with JOINs

The FROM clause is translated into SQL as written in ADQL. There is no differences except the identifiers that are replaced. The tables' aliases and their case sensitivity are kept like in ADQL.

Since:
1.4
See Also: