db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jakob Braeuchi" <jbraeu...@gmx.ch>
Subject Re: Bug found, need input before submitting fix
Date Fri, 13 Dec 2002 10:35:55 GMT
hi russell,

> > do you have the same problem when using another rdbms ?
> Havent tried it, but I would assume a different rdbms would not change
> the fact that having two identically named columns in a result set

i was thinking of different join syntax. btw what dbms do you use ?

jakob

----- Original Message -----
From: "J. Russell Smyth" <drfish@cox.net>
To: "OJB Developers List" <ojb-dev@jakarta.apache.org>
Sent: Friday, December 13, 2002 9:03 AM
Subject: Re: Bug found, need input before submitting fix


> On Fri, 2002-12-13 at 00:50, Jakob Braeuchi wrote:
> > hi russell,
> >
> > could you please send me the oql-queries and the resulting sql.
> > when you query for class A the select should only contain columns of A
> > except in join clause.
> > an other exception is the use of report queries where you specify the
> > columns you want to have in the resultset.
>
> I will send these in the morning - the queries we had problems with are
> at my office ;-)
> >
> > have you also come accross this problem using pure pb-queries ?
> yes. Pure PB has same problem. I will also send an example of this.
>
> > do you have the same problem when using another rdbms ?
> Havent tried it, but I would assume a different rdbms would not change
> the fact that having two identically named columns in a result set
> causes an ambiguity. It may not cause immediate problems if for example
> the cols are hashed differently and "by chance" the correct value gets
> in where you are looking for it, but it is still a problem!
>
> > ----- Original Message -----
> > From: "J. Russell Smyth" <drfish@cox.net>
> > To: "OJB Developers List" <ojb-dev@jakarta.apache.org>
> > Sent: Friday, December 13, 2002 6:19 AM
> > Subject: Re: Bug found, need input before submitting fix
> >
> >
> > > 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>
> > > >
> > >
> > >
> > >
> > > --
> > > 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>
> >
>
>
>
> --
> 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