db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "J. Russell Smyth" <drf...@cox.net>
Subject Re: Bug found, need input before submitting fix
Date Fri, 13 Dec 2002 05:19:13 GMT
Actually, several situations would cause this:

class A{
  int id;
  String data;
  Collection bees;
}
class B{
  int id;
  int fkToA;
  String data;
}

first, under ODMG, the sql generated tends to add all columns of all
objects involved into the select.

Second, if we are trying to get all a's with b's containing
data="somedata" the query is sometimes optimized to do a join that
includes the data from both classes.

I dont have the exact queries here (I am away from the office, and a
co-worker is doing most of this particular piece of work, I am just
working with him to determine what is our problem and what is OJB's) but
it does happen and is happening to us. Some of it may also be caused by
the incomplete ODMG OQL not quite doing what we want.

There is also the problem of OTHER columns returned in a select that are
duped - not just id columns!

Russell

On Thu, 2002-12-12 at 15:47, Jakob Braeuchi wrote:
> hi russell,
> 
> i can see the problem with the multiple ID columns in resultset. but i do
> not understand where it comes from. all my tables have a row called ID used
> as OID but i never had a problem with it.
> actually what i do not know why you have IDs of both tables in the SELECT ??
> 
> jakob
> 
> ----- Original Message -----
> From: "J. Russell Smyth" <drfish@cox.net>
> To: "OJB Developers List" <ojb-dev@jakarta.apache.org>
> Sent: Thursday, December 12, 2002 8:30 AM
> Subject: Bug found, need input before submitting fix
> 
> 
> > 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
> >
> >
> >
> > --
> > To unsubscribe, e-mail:   <mailto:ojb-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail: <mailto:ojb-dev-help@jakarta.apache.org>
> >
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:ojb-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:ojb-dev-help@jakarta.apache.org>
> 



Mime
View raw message