Confusing error returned when trafodion uninitialized

[Roberta Marton]

When Trafodion is uninitialized and a get statement is executed, error 4082 is returned with an invalid object name.

For example:

SQL>get tables
+>;

*** ERROR[8448] Unable to access Hbase interface. Call to ExpHbaseInterface::getRowOpen returned error HBASE_OPEN_ERROR(-703). Cause:
org.apache.hadoop.hbase.TableNotFoundException: TRAFODION._MD_.OBJECTS
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.locateRegionInMeta(HConnectionManager.java:1241)
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.locateRegion(HConnectionManager.java:1110)
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.locateRegion(HConnectionManager.java:1067)
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getRegionLocation(HConnectionManager.java:908)
org.apache.hadoop.hbase.client.RegionServerCallable.prepare(RegionServerCallable.java:72)
org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:113)
org.apache.hadoop.hbase.client.HTable.get(HTable.java:773)
org.trafodion.sql.HBaseAccess.HTableClient.startGet(HTableClient.java:335)
. [2014-12-16 19:10:04]
*** ERROR[1393] Trafodion is not initialized on this system. Do 'initialize trafodion' to initialize it. [2014-12-16 19:10:04]

-> *** ERROR[4082] Object T does not exist or is inaccessible. [2014-12-16 19:10:04]

Expecting to see OBJECTS in the error message but "T" is returned. T is not a valid name.

The get tables code performs the following statement:

select object_name from TRAFODION.\"_MD_\".OBJECTS T where T.catalog_name = 'TRAFODION' and T.schema_name = 'SEABASE' and T.object_type = 'BT' for read uncommitted access order by 1 ;

When error 4082 is generated in NATableDB::get, the qualifier T (corrName.getExposedNameAsAnsiString) is specified instead of the actual name of OBJECTS (corrName.getQualifiedNameObj().getObjectName).

[Anoop Sharma (anoop-sharma)]

This is not an issue with initialize and is expected behavior.

When a table in a query is correlated, then the correlation name is returned
by binder/compiler in case of an error accessing it.
For an internal query against metadata, if that metadata doesn't exist, then
the correlated name used in the internal metadata query is returned.

This behavior has always been like this (from pre-trafodion days) and should
not be treated as a a bug.

Has this case been filed to change the binder behavior and return the
name of the underlying table in case of an error? What if the underlying
table is a derived table or another query?

Here is a example of a query that accesses table ZZ which
does not exist. The error msg shows correlated name T.

>>prepare s from select * from zz t;

*** ERROR[4082] Object T does not exist or is inaccessible.

*** ERROR[8822] The statement was not prepared.

>>

If table ZZ exists, then other errors(like a missing columns) also refer to the correlated name:

>>prepare s from select * from zz t where t.a = 1;

*** ERROR[4003] Column T.A is not a column in table T, or, after a NATURAL JOIN or JOIN USING, is no longer allowed to be specified with a table correlation name.

*** ERROR[8822] The statement was not prepared.

>>

We should document this behavior and close this case.

[Roberta Marton (roberta-marton)]

This case was written at the request of someone who reported it as an error. The person did not know what T is and rightly so.

This may or may not be on purpose but it is not clear when the corrName should be used and when the real name should be used. In the same procedure (and other procedures in the file) sometimes the corrName is used in the error and sometimes the real name.

Also, independent of current behavior we should return meaningful error information. If we decide not to fix it here, then we could change our internal queries to not use correlation names, consistent correlation names, or something else. This will at least give the requester information that is understandable.