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 in 1:n Collection or...?
Date Fri, 09 Jul 2004 17:08:46 GMT
hi carsten,

thanks for your bug hunting. afaik this problem has come up some time ago, 
that's why i introduced jdbcTypes for queries. i'll check this asap.
one thing i do not understand is, why it depends on field sequence ?

jakob

Carsten Ziegeler wrote:

> Ok, I found the problem! (I now refer to using field-ref
> for the inverse foreign key).
> 
> Everything went fine until the associateBatched method
> in the CollectionPrefetcher.
> 
> In this method first all owners are put into a HashMap
> by their Identity.
> Then in a loop for each fetched child an Identiy object
> is created and this is used the fetched the corresponding
> owner from the HashMap.
> For any reason, the fkValue of the owner is
> a Long while the fkValue of the child is an Integer! Both
> have the correct value!
> 
> So, the equals method in the Identity class fails in line:
> 314/315 as a Long doesn't equal to an Integer (although
> the value is equal)
> 
>                 result = (m_pkValues[i] == null) ? (otherPkValues[i] ==
> null)
>                         : m_pkValues[i].equals(otherPkValues[i]);
> 
> As all of my keys are Integers, I wondered how the LONG gets
> into the value. I debugged this and then found the problem.
> (I don't have any knowledge about OJB internals, so the following
> are some guesses based on method/variable names)
> 
> My data objects have the id (primary key) as an instance variable stored
> in a variable of type "long". Now it seems that the Identity object
> of the owner is created based on the class description (using
> "long" as the type for the primary key. Instead, the Identity object
> for the children of the collection are based on the sql-type
> from the mapping which is an INTEGER.
> 
> Changing my instance variable from "long" to "int" for the primary key
> solved the problem.
> 
> So, is this a bug or a known problem?
> 
> Carsten
> 
> 
> 
>>-----Original Message-----
>>From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de] 
>>Sent: Friday, July 09, 2004 8:42 AM
>>To: 'OJB Developers List'
>>Subject: RE: Bug in 1:n Collection or...?
>>
>>Ok, will do that - I already debugged this a little bit and 
>>for me - without any knowledge about ojb internals - it 
>>looked ok. Except the comparission of the identity objects.
>>As soon as I have time, I will report back.
>>
>>Carsten 
>>
>>
>>>-----Original Message-----
>>>From: Jakob Braeuchi [mailto:jbraeuchi@gmx.ch]
>>>Sent: Thursday, July 08, 2004 7:01 PM
>>>To: OJB Developers List
>>>Subject: Re: Bug in 1:n Collection or...?
>>>
>>>hi carsten,
>>>
>>>i cannot confirm this behaviour, i was moving the 'parent pointer' 
>>>field to different locations and it worked ??
>>>i think you should try tho debug
>>>QueryReferenceBroker#retrieveCollection,
>>>this could help us a lot ;)
>>>
>>>tia
>>>jakob
>>>
>>>
>>>>whoa, good find.
>>>>
>>>>-Brian
>>>>
>>>>On Jul 8, 2004, at 9:49 AM, Carsten Ziegeler wrote:
>>>>
>>>>
>>>>>Some more interesting things (and this time I think it is
>>>
>>>a bug :) ):
>>>
>>>>>The order in the class-descriptor is important! If I use:
>>>>>
>>>>><class-descriptor class="B" table="b">
>>>>>  <field-descriptor name="id" ...>
>>>>>  <field-descriptor name="refToA" id="7" .../>
>>>>>  <field-descriptor name="someField"/>
>>>>>  <reference-descriptor name="a".../> </class-descriptor>
>>>>>
>>>>>then the collection from class A containing the bs is 
>>
>>empty again!
>>
>>>>>If I exchange the two fields "refToA" and "someField" it
>>>
>>>works again
>>>
>>>>>(partially) and each object of A has exactly one B (not
>>>
>>>all, but at
>>>
>>>>>least one :) ).
>>>>>
>>>>>WDYT?
>>>>>
>>>
>>>>>Carsten
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
>>>>>>Sent: Thursday, July 08, 2004 1:30 PM
>>>>>>To: ojb-dev@db.apache.org
>>>>>>Subject: Bug in 1:n Collection or...?
>>>>>>
>>>>>>I'm trying to get a simple 1:n relationship working, 
>>
>>here is the
>>
>>>>>>(stripped) mapping:
>>>>>>
>>>>>><class-descriptor class="A" table="a">
>>>>>>
>>>>>> <field-descriptor name="id" column="ID" jdbc-type="INTEGER"
>>>>>>                   primarykey="true" autoincrement="true"/>
>>>>>>
>>>>>> <collection-descriptor name="bs"
>>>>>>               element-class-ref="B"
>>>>>>               auto-retrieve="true">
>>>>>>   <inverse-foreignkey field-ref="refToA"/> 
>>>>>></collection-descriptor>
>>>>>>
>>>>>></class-descriptor>
>>>>>>
>>>>>><class-descriptor class="B" table="b">
>>>>>>
>>>>>> <field-descriptor name="id" column="ID" jdbc-type="INTEGER"
>>>>>>                   primarykey="true" autoincrement="true"/>
>>>>>>
>>>>>> <field-descriptor name="refToA" column="reftoa"
>>>>>>                          jdbc-type="INTEGER"
>>>>>>                          access="anonymous" />
>>>>>>
>>>>>> <reference-descriptor name="a"
>>>>>>                          class-ref="A">
>>>>>>    <foreignkey field-ref="refToA"/>  </reference-descriptor>
>>>>>>
>>>>>></class-descriptor>
>>>>>>
>>>>>>When getting all As using a query, the collection of each A 
>>>>>>containing Bs is always empty. The interesting thing 
>>
>>is, that an 
>>
>>>>>>SQL statement to fetch the Bs is processed and the Bs
>>>
>>>are loaded. 
>>>
>>>>>>But somehow they are not added to the collection.
>>>>>>
>>>>>>The reverse, fetching B works. They have the correct
>>>
>>>relation set
>>>
>>>>>>back to an A object.
>>>>>>
>>>>>>Now for the interesting part :) If I use:
>>>>>>   <inverse-foreignkey field-id-ref="7"/>
>>>>>>
>>>>>>and give the "refToA" field the id "7" then the
>>>
>>>collection of A is
>>>
>>>>>>not empty but contains the first associated B but never all!
>>>>>>
>>>>>>So, question is: is this a bug or am I just too stupid and did 
>>>>>>oversee something?
>>>>>>
>>>>>>I tried this with 1.0.0 and the first part with current CVS.
>>>>>>
>>>>>>Carsten
>>>>>>
>>>>>>Carsten Ziegeler
>>>>>>Open Source Group, S&N AG
>>>>>>http://www.s-und-n.de
>>>>>>http://www.osoco.net/weblogs/rael/
>>>>>>
>>>>>>
>>>>>>
>>>
>>>-------------------------------------------------------------------
>>>
>>>>>>-- To unsubscribe, e-mail: 
>>
>>ojb-dev-unsubscribe@db.apache.org For 
>>
>>>>>>additional commands, e-mail: ojb-dev-help@db.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>--------------------------------------------------------------------
>>>
>>>>>- To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org For 
>>>>>additional commands, e-mail: ojb-dev-help@db.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>---------------------------------------------------------------------
>>
>>>>To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org For 
>>>>additional commands, e-mail: ojb-dev-help@db.apache.org
>>>>
>>>
>>>--
>>>"Sie haben neue Mails!" - Die GMX Toolbar informiert Sie 
>>
>>beim Surfen!
>>
>>>Jetzt aktivieren unter http://www.gmx.net/info
>>>
>>>
>>>
>>
>>---------------------------------------------------------------------
>>
>>>To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org For 
>>>additional commands, e-mail: ojb-dev-help@db.apache.org
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org For 
>>additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Mime
View raw message