Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 1.5.0
-
Component/s: None
-
Labels:None
Description
getTables on the metadata of a connection does not work (returns empty ResultSet) with avatica remoting using a JdbcMeta.
connection.getMetaData().getTables(null, null, null, null);
The problem seems to be related to the String[] types argument of the getTables method, this works as expected:
connection.getMetaData().getTables(null, null, null, new String[]{"TABLE"});
I think it boils down to the JdbcMeta#toArray(List<String> typeList) method which returns an empty array in stead of null, resulting in the creation of an incorrect typeFilter in CalciteMetaImpl#getTables (line 254).
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
Proper patch with test this time.
I had to fix the protobuf RPC as well by adding an extra boolean in the TablesRequest to express whether the typeList is empty or null. This is similar to what was already done in FetchRequest for parameterValues.
I also noticed a documentation glitch in howto.md. It explains to use protobuf-3.0.0-beta-1 while I had to use protobuf-3.0.0-alpha-2 to make it work (same as in pom.xml). This might also suggest the maven dependency needs to be updated to beta1 of course.
I also noticed a documentation glitch in howto.md. It explains to use protobuf-3.0.0-beta-1 while I had to use protobuf-3.0.0-alpha-2 to make it work (same as in pom.xml). This might also suggest the maven dependency needs to be updated to beta1 of course.
You're right. I saw there was a newer release. Should probably move to that. I will file an issue.
I had to fix the protobuf RPC as well by adding an extra boolean in the TablesRequest to express whether the typeList is empty or null. This is similar to what was already done in FetchRequest for parameterValues.
Sounds right. The way default/optional values are handled in protobuf3 make me a little sad (over protobuf2).
Might you also be able to add a unit test to catch the protobuf serialization for TablesRequest too? Might be simple to add to ProtobufTranslationImplTest. I can always swing back later and grab it.
Otherwise, LGTM.
I'm testing in https://github.com/julianhyde/incubator-calcite/tree/905-get-tables; looks good so far.
I've fixed the doc issue in the same patch (but won't re-generate the site for now).
getUDTs has the same issue as getTables. (It has a field 'int[] types')
If you would like me to hold so you can fix getUDTs and add a protobuf test, let me know.
Fixed in http://git-wip-us.apache.org/repos/asf/incubator-calcite/commit/73e81ac2. Thanks for the patch, Jan Van Besien!
Resolved in release 1.5.0 (2015-11-10)
Patch looks good, but can you also supply a unit test.