You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@metamodel.apache.org by "Dennis Du Krøger (JIRA)" <ji...@apache.org> on 2017/07/06 07:04:00 UTC

[jira] [Comment Edited] (METAMODEL-1142) Support Oracle synonym feature

    [ https://issues.apache.org/jira/browse/METAMODEL-1142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16075405#comment-16075405 ] 

Dennis Du Krøger edited comment on METAMODEL-1142 at 7/6/17 7:03 AM:
---------------------------------------------------------------------

Okay, if that's enough, we should be able to work around it, though I'd argue that TableType.SYNONYM should be default, at least if I understand the feature correctly. Why would you create synonyms to another schema/user if you didn't want to see it by default (though see below for a possible reason that you wouldn't)?

I'll have to test it, but it does sound like we might still need to include the connection property, here's the description of "includeSynonyms":
{quote}
"true" to include column information from predefined "synonym" SQL entities when you execute a DataBaseMetaData getColumns() call; equivalent to connection setIncludeSynonyms() call (default value is "false")
{quote}
(https://docs.oracle.com/cd/B10501_01/java.920/a96654/basic.htm#1006248)

... Though it does seem like it would be the next problem we'll run into and not the current one, as we're currently not even seeing the table, and this would "only" be a problem when getting the actual columns of the table. One could hope that includeSynonyms would only affect getting wildcard columns (e.g. all columns regardless of source table), as it's billed as disabled for performance reasons:
{quote}Similar to setRemarksReporting, getColumns performs extremely slow if information about synonyms has to be included, because it neccessitates an outer join so, by default, the JDBC driver will not report information about synonyms.
{quote}
(https://docs.oracle.com/cd/E11882_01/appdev.112/e13995/oracle/jdbc/OracleConnection.html#setIncludeSynonyms_boolean_)

I don't believe that will affect us performance wise, as our only call to getColumns is for single tables' columns, but might still very well be a good reason _not_ to enable includeSynonyms by default.

Under all circumstances, I'll need to do some more digging, but I'll need access to an Oracle server to do that digging. Stay tuned! :)


was (Author: losd):
Okay, if that's enough, we should be able to work around it, though I'd argue that TableType.SYNONYM should be default, at least if I understand the feature correctly. Why would you create synonyms to another schema/user if you didn't want to see it by default (though see below for a possible reason that you wouldn't)?

I'll have to test it, but it does sound like we might still need to include the connection property, here's the description of "includeSynonyms":
{quote}
"true" to include column information from predefined "synonym" SQL entities when you execute a DataBaseMetaData getColumns() call; equivalent to connection setIncludeSynonyms() call (default value is "false")
{quote}
(https://docs.oracle.com/cd/B10501_01/java.920/a96654/basic.htm#1006248)

... Though it does seem like it would be the next problem we'll run into and not the current one, as we're currently not even seeing the table, and this would "only" be a problem when getting the actual columns of the table, though one could hope that includeSynonyms would only affect getting wildcard columns (e.g. all columns regardless of source table), as it's billed as disabled for performance reasons:
{quote}Similar to setRemarksReporting, getColumns performs extremely slow if information about synonyms has to be included, because it neccessitates an outer join so, by default, the JDBC driver will not report information about synonyms.
{quote}
(https://docs.oracle.com/cd/E11882_01/appdev.112/e13995/oracle/jdbc/OracleConnection.html#setIncludeSynonyms_boolean_)

I don't believe that will affect us, performance wise, as our only call is for single tables, but might still very well be a good reason _not_ to enable includeSynonyms by default.

Under all circumstances, I'll need to do some more digging, but I'll need access to an Oracle server to do that digging. Stay tuned! :)

> Support Oracle synonym feature
> ------------------------------
>
>                 Key: METAMODEL-1142
>                 URL: https://issues.apache.org/jira/browse/METAMODEL-1142
>             Project: Apache MetaModel
>          Issue Type: Improvement
>            Reporter: Dennis Du Krøger
>            Priority: Minor
>
> The Oracle database has a "synonym" feature, so that tables in one schema can be visible in another. Unfortunately this feature is disabled by default (meaning those tables are still invisible), and unfortunately it is not possible to enable as part of the connection string, it needs to be done with the connection properties, at least according to this SO answer: https://stackoverflow.com/questions/14455566/how-can-i-use-connection-string-along-with-jdbc-url/14455647, testing seems to confirm.
> We should probably add this (either by default or as an option), as it seems to be an expected feature.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)