db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mamta Satoor <msat...@gmail.com>
Subject Re: [PATCH] Jira-189 ResultSetMetaData.getSchemaName and ResultSetMetaData.isWritable donot return correct values
Date Fri, 22 Apr 2005 16:43:36 GMT
Hi Dan,

I did some research into this. You are right that for the sql
select * from a.t as X
the existing code will return ABC using both getTableName and
getSourceTableName. Looking at the history of ColumnReference before
the code was
contributed, the getSourceTableName was added to Cloudscape so that
ResultSetMetaData.getTableName will return the correct value which is
base table
name. Seems like over the time, this functionality got broken again. 

In my code line, I tried changing ColumnReference.getSourceTableName
to following
public String getSourceTableName()
return ((source != null) ? source.getTableName() : null);

But, that did not solve the problem. The source.getTableName() invokes
ResultColumn.getTableName which is currently coded as follows
public String getTableName()
  if (tableName != null)
    return tableName;
  if ((columnDescriptor!=null) &&
    (columnDescriptor.getTableDescriptor() != null))
    return columnDescriptor.getTableDescriptor().getName();
    return expression.getTableName();

In the code above, the first 2 if conditions return false and hence
expression.getTableName() get called which returns ABC for the sql
above. And this
is the problem in my opinion. The 2nd if condition needs to succeed in
order to get the correct value for table name(currently, the 2nd if
returns false because columnDescriptor.getTableDescriptor() returns
null). columnDescriptor has its table descriptor set to null since it
instantiated via SYSCOLUMNSRowFactory which passes the uuid for the
table but not the table descriptor. I tried changing
2nd constructor(the one which doesn't get table descriptor passed to
it) to try to get the table descriptor from the uuid by calling
getDataDictionary.getTableDescriptor(uuid), but it gives me Raw Store
internal error. I will continue to research but does someone looking
at this
explanation have any thoughts on the program flow or issue in general?


On 4/20/05, Daniel John Debrunner <djd@debrunners.com> wrote:
> The patch applies fine and passes the tests but I need some
> clarification on some methods in ColumnReference.
> ColumnReference has these class specific methods
> getSourceTableName()
> getSourceSchemaName() [added by this contribution]
> and because it is a ValueNode it also has
> getTableName
> getSchemaName
> Mamta, can you clarify the difference between the getSource*Name methods
> and get*Name methods? Eventually as comments in the javadoc for these
> methods, but some discussion on the list may be useful.
> I'm worried because most of the bugs around correlation names I think
> were due to having multiple methods with similar and maybe misleading
> names but no clear definition of what they returned.
> In this specific case, my gut reaction from the names of the
> getSource*Name methods is that they return the actual name of the
> underlying table the column comes from. But looking the implementation &
> comments of getTableName and getSourceTableName in ColumnReference.java
> it seems in this case
> select * from a.t as X
> that both methods will return X.
> Dan.

View raw message