db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Waibel <arm...@apache.org>
Subject Re: Opinion on patch please?
Date Tue, 28 Sep 2004 19:26:04 GMT
adamandeve@netspace.net.au wrote:

> Did you get the attached test cases (that specifically tested the changes) and
> the diff patch file, I was unaware of whether our firewall software at work
> stripped them off the email.
>

I don't get any test cases attached with your post. Please send these 
files directly to my account.
Good luck! ;-)

regards,
Armin


> Quoting Armin Waibel <arminw@apache.org>:
> 
> 
>>Hi Adam,
>>
>>I don't see a problem to apply your patch.
>>Currently we don't have a test case showing the described issue with m:n 
>>relations, but test suite locally pass with patched DescriptorRepository 
>>class, so I will check in your patch ASAP.
>>
>>regards,
>>Armin
>>
>>
>>Adam Jenkins wrote:
>>
>>>   
>>>Class: DescriptorRepository
>>>Maintainers: Thomas Mahler, Leandro Rodrigo
>>>
>>>
>>>Hi All,
>>>
>>>I want to make the following code changes and submit as patch, however
>>
>>first
>>
>>>I really would appreciate the opinion of regular commiters.  The change I
>>>wish to make is in class
>>>org.apache.ojb.broker.metadata.DescriptorRepository, method
>>>getTopLevelClass(java.lang.Class) in the following block of code.
>>>
>>>
>>>    168                 else
>>>    169                 {
>>>    170                     // check if class is persistence capable
>>>    171                     getDescriptorFor(clazz);
>>>    172                     retval = clazz;
>>>    173                 }
>>>    174                 m_topLevelClassTable.put(clazz, retval);
>>>
>>>On line 171, if clazz isn't mapped directly, but a superclass or interface
>>>of clazz is, the getDescriptorFor call accurately resolves to the
>>
>>descriptor
>>
>>>for the correct superclass/interface.  However, on line 172, the
>>
>>returnvalue
>>
>>>is being assigned directly to the class that we're interrogating, not the
>>>class specified in the descriptor.  This means that with respect to
>>
>>storing
>>
>>>and loading we can support subclasses and interface implementation,
>>
>>however
>>
>>>when resolving the top class (especially when being called from Identity
>>>init method), we can't support the same functionality.  This has
>>>implications when storing/retrieving objects with m:n relationship in this
>>>scenario.  It would be a fairly simple change to do the following which
>>>would solve the problem:
>>>
>>>    168                 else
>>>    169                 {
>>>    170                     // check if class is persistence capable
>>>    171                     ClassDescriptor tmpDescriptor =
>>>getDescriptorFor(clazz);
>>>    172
>>>    173                     //Adam Jenkins: use the class that is
>>
>>associated
>>
>>>with
>>>    174                     //the descriptor instead of the actual class.
>>>    175                     retval = tmpDescriptor.getClassOfObject();
>>>    176
>>>    177                     //retval = clazz;
>>>    178                 }
>>>    179                 m_topLevelClassTable.put(clazz, retval);
>>>
>>>
>>>Thoughts, queries, comments, objections?
>>>
>>>Cheers
>>>Adam
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------
> This email was sent from Netspace Webmail: http://www.netspace.net.au
> 
> 
> ---------------------------------------------------------------------
> 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