[TAP] case sensitivity of query
Patrick Dowler
patrick.dowler at nrc-cnrc.gc.ca
Mon Mar 2 10:28:35 PST 2009
(in response to a point in Gerard's email of 2009-02-19)
TAP 0.4 section 2.3.4 (QUERY parameter) says that the query string is case
sensitive even though ADQL (and SQL92 before it) are not case-sensitive. This
is worth airing as the reason for this may otherwise be lost.
It turns out that very late in the process of standardising ADQL 2.0 (at the
Baltimore Interop, specifically) the point was raised that some existing
databases have case-sensitive table and/or column names while ADQL is not
case sensitive. Specifically, this means that the ADQL -> SQL translation
performed by a TAP service with that sort of db backend would have to end up
with the correct case for table/column/etc (e.g. names of things the caller
discovers in the service metadata).
I see two possible options that would make things work:
1. The service exposes the correct case-sensitive names and TAP clients do not
modify these names in any way. This is less extreme than what is stated in
2.3.4 but in the same spirit (which is explained in that subsection). We
could modify the text to say that the query is not case sensitive except in
this one respect.
2. The service has to accept a completely non-case query and if the backend db
is case-sensitive the service has to map the table and column names from the
metadata as necessary to make it work. This would get harder if the service
really used case to distinguish things (like columns ra,dec,RA,DEC) but could
still be done as long as the column names in the exposed metadata are unique.
I don't know if anyone has/would make a database schema that way...
Note: It should be noted that the current metadata (TBD) plan is that the
service exposes the fully-qualified table name (e.g. with as many of the
catalog and schema specified as are needed for the query to be correct) and
the client is expected to use the fully-qualified table names "as-is" and not
to parse them to get at these constructs. This greatly simplifies the
metadata (esp. the XML schema, I understand) and works fine. Thus, clients
are already supposed to use use table names "as-is" and #1 above just extends
it to include case and apply to column names.
Note: For TAP implementors where the DB is not case sensitive, neither of
these effect you, but #1 marginally effects the client.
Please comment asap.
--
Patrick Dowler
Tel/Tél: (250) 363-0044
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9E 2M7
Centre canadien de donnees astronomiques
Conseil national de recherches Canada
5071, chemin West Saanich
Victoria (C.-B.) V9E 2M7
More information about the dal
mailing list