Return-Path: Mailing-List: contact ojb-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list ojb-dev@jakarta.apache.org Received: (qmail 370 invoked by uid 98); 12 Dec 2002 07:31:31 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Received: (qmail 332 invoked from network); 12 Dec 2002 07:31:29 -0000 Received: from daedalus.apache.org (HELO apache.org) (63.251.56.142) by nagoya.betaversion.org with SMTP; 12 Dec 2002 07:31:29 -0000 Received: (qmail 85880 invoked by uid 500); 12 Dec 2002 07:30:09 -0000 Received: (qmail 85872 invoked from network); 12 Dec 2002 07:30:09 -0000 Received: from fed1mtao01.cox.net (68.6.19.244) by daedalus.apache.org with SMTP; 12 Dec 2002 07:30:09 -0000 Received: from drfish.ods.org ([68.104.165.146]) by fed1mtao01.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20021212073020.RDIH27128.fed1mtao01.cox.net@drfish.ods.org> for ; Thu, 12 Dec 2002 02:30:20 -0500 Subject: Bug found, need input before submitting fix From: "J. Russell Smyth" To: OJB Developers List Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8-3mdk Date: 12 Dec 2002 00:30:20 -0700 Message-Id: <1039678220.19756.45.camel@drfish.ods.org> Mime-Version: 1.0 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N We have stumbled across an interesting problem. In our application, we have two tables/objects, each which have an "ID" column, which is our OID for the particular object. We have been having a bear of a time with a query that joins these two tables.. we finally tracked the problem to the identically named columns. Inside DefaultRowReader, when the JdbcAccess class is used to turn a row into an object, it does JdbcAccess.getObjectFromColumn, which in turn calls ResultSet.getXXX( columnId ). This is where the problem is. In our case, there are now two "ID" columns in the result set. so when OJB is trying to populate our first object (call it object A) it does rs.getInt( "ID" ). when populating object B, it will do the same thing - obviously the result for one or the other will be wrong! In our case, some bad mojo in the way that SAPDB hashes the column identifiers insured us getting the wrong ide placed into object A, making the problem abundantly clear. My co-worker has written a temporary fix that simply aliases all columns in a query as TABLE_COLUMN in org.apache.ojb.broker.accesslayer.sql.SqlSelectStatement and org.apache.ojb.broker.accesslayer.sql.SqlSelectByPkStatement by adding "AS [field.getClassDescriptor().getFullTableName())]_[field.getColumnName())]" to each column descriptor in the query ("select A0.ID AS TAB1_ID, A1.ID AS TAB2_ID from TAB1 A0, TAB2 A1 WHERE .... ") and made org.apache.ojb.broker.accesslayer.JdbcAccess look for this name by changing fld.getColumnName() to fld.getClassDescriptor().getFullTableName() + "_" + fld.getColumnName() I have begun to write a test case, and am looking to see if there is a cleaner way to do this, but I wanted to get input from the group before I went to far - perhaps someone with more experience with the OJB internals can see a better fix faster than i, or has even run into this before? If not, I would still welcome any input, and will continue to work on test case and fix. Thanks Russell