db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From adamand...@netspace.net.au
Subject Re: Opinion on patch please?
Date Tue, 28 Sep 2004 18:42:34 GMT
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.

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


Mime
View raw message