db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian McCallister <mccallis...@forthillcompany.com>
Subject Re: Opinion on patch please?
Date Wed, 15 Sep 2004 01:55:56 GMT
I applied your changes and it didn't break anything ELSE.... sadly we 
have a few failing unit tests at the moment, including one dealing with 
extents.

Haven't checked anything in, yet, but so no reason not to in near 
future.

-Brian

On Sep 14, 2004, at 9:17 PM, Adam Jenkins wrote:

> Yep, I will submit a proper patch (with unit test) this time tomorrow 
> (will
> code it up tonight [now + 7hrs]).  Just thought I'd run it by everyone 
> first
> as I'm fairly new to the code base.
>
> Thanks for the quick response.
>
> -----Original Message-----
> From: Brian McCallister [mailto:mccallister@forthillcompany.com]
> Sent: Wednesday, 15 September 2004 11:11 AM
> To: OJB Developers List
> Subject: Re: Opinion on patch please?
>
>
> Makes sense to me. Applying and testing (and running to store).
>
> Any chance you can submit a unit test exercising this?
>
> -Brian
>
> On Sep 14, 2004, at 8:55 PM, 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



---------------------------------------------------------------------
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