|
From: Robert M. <rob...@gm...> - 2010-01-26 00:53:31
|
Gerd, I definitely agree that getColumnName() seems to be the better choice according to the documentation. I also agree that the most desireable code change is to replace getLabel with getColumnName wherever we are dynamically building SQL to send to the database. However, I was reluctant to replace all occurrences since for display purposes we should probably stick with getLabel (Users with databases that support labels probably define them for their own purpose and we should respect that). I also think that if we do this in core, then probably most if not all of Christian's custom DB2 datatypes are unnecessary. I skimmed over them so it is possible that I missed something but they seemed to be merely overriding the core implementation of getWhereClauseValue() and the like in *DataTypeComponent. I'll take another look. Rob On Mon, Jan 25, 2010 at 6:52 PM, Gerd Wagner <ger...@t-...> wrote: > Robert Manning wrote: >> >> Gerd, >> >> I think we should address this patch in our 3.1 release. It seems >> that a number of our DB2 on mainframe users run into this problem >> according to this bug: >> >> >> https://sourceforge.net/tracker/index.php?func=detail&aid=2818117&group_id=28383&atid=393414 >> >> It seems that it's for no good reason that we use >> ColumnDisplayDefinition.getLabel() rather than getColumnName(). It >> looks like Glenn chose to do that since the beginning and it was >> simply used everywhere consistently. It has occurred to me that this >> could be addressed in several ways: >> >> 1. Modify the places where we build a where clause to use >> getColumnName() instead of getLabel().(Maybe this breaks on other DBs >> ?) >> 2. Detect if the dialect is DB2 on Mainframe (z/OS, OS/400, etc.) and >> call getColumnName instead of getLabel() to build where clause. >> 3. Let the user configure an alias property to chose getColumnName() >> vs. getLabel() for where clauses (default is getLabel() as it is now). >> >> Which solution above would be your preference (or any others) ? > > It seems funny to me that this problem was reported from DB2 on mainframe > only up to now. If you look at the JDBC-API it appears to me that our way to > use column labels must cause problems when a database supports them. My > suggestion is choose the first of your ways because it seems the cleanest to > me. If then anyone complains we should treat this as an exception from the > standard way and see how we can cope with it. > > Perhaps because of the problem we should release 3.1 as a release candidate > (rc1) first, wait a month or so to see what happens and then dot he final > release. > > If you agree please tell me. I have all the necessary changes on my PC and > will commit it together with the changes in Christian's patch. I even found > some more places where the problem had to be fixed as well. Just look at the > usages of ColumnDisplayDefinition.getLabel(). > > > Christian, thanks for pointing out the problem and sorry that we didn't > realize the importance of your patch earlier. > > Gerd > > >> >> Rob >> >> >> ---------- Forwarded message ---------- >> From: Christian Gruenberg <gru...@ne...> >> Date: Sat, Jan 2, 2010 at 8:31 AM >> Subject: [Squirrel-sql-develop] DB2 for mainframe and Labels >> To: squ...@li... >> >> >> Hi, >> >> Db2 for mainframe support the labels. That means you can show >> columnnames with a displayname. But DB2 doesn't support using the >> labels in sql statements. To avoid this problem I have replaced the >> getLabel calls with getColumnName. Unfortunately the replacement is >> not only in the db2 plugin necessary but also in some general classes. >> >> You can find the patch here: >> >> https://sourceforge.net/tracker/?func=detail&aid=2924887&group_id=28383&atid=393416 >> >> I'm looking forward to some feedback, >> Christian >> >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and >> easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> Squirrel-sql-develop mailing list >> Squ...@li... >> https://lists.sourceforge.net/lists/listinfo/squirrel-sql-develop >> > > |
