Bug 43831 - Unexpected Result with mysql jdbc 5.1.5, column aliases not reported
Summary: Unexpected Result with mysql jdbc 5.1.5, column aliases not reported
Alias: None
Product: Taglibs
Classification: Unclassified
Component: Standard Taglib (show other bugs)
Version: 1.1
Hardware: All All
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
: 45183 (view as bug list)
Depends on:
Reported: 2007-11-09 12:59 UTC by Eric Quilantang
Modified: 2017-01-18 14:26 UTC (History)
1 user (show)


Note You need to log in before you can comment on or make changes to this bug.
Description Eric Quilantang 2007-11-09 12:59:48 UTC
Unexpected Result with mysql jdbc 5.1.5, column aliases not reported
see http://bugs.mysql.com/bug.php?id=21596

I suggest changing getColumnName to getColumnLabel.

Index: C:/dev/jee/workspace/standard/src/javax/servlet/jsp/jstl/sql/ResultImpl.java
(revision 593646)
(working copy)
@@ -67,7 +67,7 @@
         // Create the column name array
         columnNames = new String[noOfColumns];
         for (int i = 1; i <= noOfColumns; i++) {
-            columnNames[i-1] = rsmd.getColumnName(i);
+            columnNames[i-1] = rsmd.getColumnLabel(i);
         // Throw away all rows upto startRow
Comment 1 Kris Schneider 2007-11-09 13:13:50 UTC
(In reply to comment #0)
> I suggest changing getColumnName to getColumnLabel.

What, specifically, is the issue with getColumnName? Did it return null or an
empty string? Is this potentially a JDBC driver issue? I wouldn't support
swapping getColumnName for getColumnLabel, but if column name is null or empty,
perhaps column label could be used as a backup.
Comment 2 Kris Schneider 2007-11-09 13:21:35 UTC
(In reply to comment #1)
> Is this potentially a JDBC driver issue?


It looks like there's supposed to be a "backwards-compatible option" for the
driver that should make this work. There's also a comment that "some
frameworks/libraries don't follow the JDBC spec in using column names and
labels." So maybe column label really should be used? If anyone can point to
some definitive documentation, that would help.
Comment 3 Eric Quilantang 2007-11-09 13:35:13 UTC
(In reply to comment #2)
> If anyone can point to some definitive documentation, that would help.

couldn't find anything in the jdbc4 jsr but found this in the java6 doc

Comment 4 Eric Quilantang 2007-11-13 12:38:57 UTC
found mysql bug report that the useOldAliasMetadataBehavior default changes from
true to false from version 5.0 to 5.1.

ava     2007-11-13 13:36:49.473056600 -0600
pl.java 2007-11-13 13:41:30.707431600 -0600
        private BooleanConnectionProperty useOldAliasMetadataBehavior = new
-                       "useOldAliasMetadataBehavior",
-                       true,
-                       "Should the driver use the legacy behavior for \"AS\"
clauses on columns and tables, and only "
-                   + "return aliases (if any) for
ResultSetMetaData.getColumnName() or ResultSetMetaData.getTableName()
-                   + "rather than the original column/table name?",
-                   "5.0.4",
+                       "useOldAliasMetadataBehavior", //$NON-NLS-1$
+                       false,
+                   "5.0.4", //$NON-NLS-1$

I would still suggest changing the accessor from getColumnName to getColumnLabel
since this would reflect the intent of the developer.

Comment 5 Henri Yandell 2007-12-07 05:37:05 UTC
Looking at the spec, I see two uses for the name.

The first is to do ${row.lastName} and the second is to list the column names.

The latter is very obviously going to be improved by the change below. The
former is going to be improved in so much as presumably there's a bug when a
select statement has two entries with the same column names.

The people hurt by this change are ones with code like:

"SELECT id as identifier ..." and then using ${row.id}.

We could either:

a) Warn such people in the release notes.
b) Try to implement something whereby we get label + name and support both. As
it's not a part of the API, This would mean a custom SortedMap that allowed a
backup key.

If desirable, b) doesn't seem that hard to implement to support the ${row.id}
use case, though anyone relying on getRows() as a Map is going to see a change
in keys unless they use the same API as row.id (presumably get(Object)).

Comment 6 Eric Quilantang 2007-12-07 07:36:06 UTC
(In reply to comment #5)
> Thoughts?
I see no reason to change the api. When I alias the column, I never need to
access the field using the real column name.
Comment 7 Henri Yandell 2007-12-30 22:09:52 UTC
I've submitted a unit test to show this - the only problem is that Derby does
not do what MySQL do, so my test which should fail for MySQL in fact passes for

svn ci -m "Unit test to show this bug - if it were run against mysql. Derby does
not exhibit the JDBC change that MySQL has" test

Adding         test/org/apache/taglibs/standard/tag/el/sql/Test43831.java
Adding         test/web/org/apache/taglibs/standard/tag/el/sql/Test43831.jsp
Transmitting file data ..
Committed revision 607682.
Comment 8 Henri Yandell 2007-12-30 22:11:45 UTC
Resolving this bug as suggested:

svn ci -m "Switching from getColumnName to getColumnLabel as per #43831. JDBC
spec indicates that the name should be returned rather than the label, and it
seems far more likely that a JSTL user will want the label despite the name of
the variable 'columnNames'. " src/javax 

Sending        src/javax/servlet/jsp/jstl/sql/ResultImpl.java
Transmitting file data .
Committed revision 607683.
Comment 9 Jeremy Boynes 2010-10-23 14:20:15 UTC
*** Bug 45183 has been marked as a duplicate of this bug. ***
Comment 10 Sven Schliesing 2017-01-18 14:26:57 UTC
Is there any information for which version this bug is fixed? I can see the change in trunk but can't find any released version containing the fix (https://svn.apache.org/viewvc?view=revision&revision=607683).

The last released version is 1.2.5 (http://svn.apache.org/viewvc/tomcat/taglibs/standard/tags/taglibs-standard-1.2.5/impl/src/main/java/org/apache/taglibs/standard/tag/common/sql/) but I can't find any hint that the fix made it in this release.