Hello,
Here's the patch I cooked up. Sorry for not attaching the patch file,
but every mail with attachment I sent was rejected by the mail servers.
As for the patch, when materializing a row from the database, we can
just check the ojbConcreteClass whenever this is present and use it to
determine the fields that need to be materialized. This helps
performance whenever the ojbConcreteClass is present in the row of the
resultSet and also avoids materializing every column of the table (which
can lead to problems when field converters are used).
Best regards,
Luis Cruz
###### START OF PATCH ######
Index: RowReaderDefaultImpl.java
===================================================================
RCS file:
/home/cvspublic/db-ojb/src/java/org/apache/ojb/broker/accesslayer/RowReaderDefaultImpl.java,v
retrieving revision 1.30.2.1
diff -u -r1.30.2.1 RowReaderDefaultImpl.java
--- RowReaderDefaultImpl.java 9 Aug 2004 07:51:26 -0000 1.30.2.1
+++ RowReaderDefaultImpl.java 23 Aug 2004 14:46:50 -0000
@@ -24,6 +24,7 @@
import org.apache.ojb.broker.PersistenceBrokerException;
import org.apache.ojb.broker.metadata.ClassDescriptor;
import org.apache.ojb.broker.metadata.FieldDescriptor;
+import org.apache.ojb.broker.metadata.JdbcType;
import org.apache.ojb.broker.util.ClassHelper;
import org.apache.ojb.broker.util.logging.LoggerFactory;
@@ -171,7 +172,28 @@
}
else
{
- fields =
m_cld.getRepository().getFieldDescriptorsForMultiMappedTable(m_cld);
+ // If we know what concrete class to use, then we don't
have to guess the fields.
+ FieldDescriptor concreteClassFD =
m_cld.getOjbConcreteClassField();
+ ClassDescriptor classDescriptor = m_cld;
+ if (concreteClassFD != null)
+ {
+ try
+ {
+ JdbcType jdbcType =
concreteClassFD.getJdbcType();
+ String val = (String)
jdbcType.getObjectFromColumn(rs, concreteClassFD.getColumnName());
+ classDescriptor =
m_cld.getRepository().getDescriptorFor(val);
+ fields = classDescriptor.getFieldDescriptions();
+ }
+ catch (SQLException e)
+ {
+ // I think this is never reached because
(concreteClassFD != null)
+ // but let's play it on the safe side.
+ classDescriptor = m_cld;
+ fields =
classDescriptor.getRepository().getFieldDescriptorsForMultiMappedTable(classDescriptor);
+ }
+ } else {
+ fields =
classDescriptor.getRepository().getFieldDescriptorsForMultiMappedTable(classDescriptor);
+ }
}
readValuesFrom(rs, row, fields);
}
###### END OF PATCH ######
On Sat, 2004-08-21 at 11:21, Armin Waibel wrote:
> Hi Luis,
>
> I think this method returns all fields to support interfaces and
> abstract classes too. But I agree you are right, if the ClassDescritor
> belongs to a "normal" class only the associated fields should be
> returned. But I'm not familiar with this stuff (side-effects?), so did
> you write a patched version of DescriptorRepository? Do all junit tests
> pass?
>
> regards,
> Armin
>
> Luis Cruz wrote:
> > Hello,
> >
> > We are working with OJB 1.0 release and we found a bug a few weeks ago.
> > Only now have we found time to determine the origin of the bug so here
> > goes.
> >
> > In the DescriptorRepository class, in particular, in the method:
> >
> > getFieldDescriptorsForMultiMappedTable
> >
> > the following snip of code is used to obtain the field descriptors of
> > the target class descriptor:
> >
> > synchronized (m_multiMappedTableMap)
> > {
> > retval =
> > getAllMappedColumns(getClassesMappedToSameTable(targetCld));
> > m_multiMappedTableMap.put(targetCld.getClassNameOfObject(),
> > retval);
> > }
> >
> > Basically this code is retrieving all the field descriptors of all the
> > class descriptors mapped to the same table. This is a bug is it not? If
> > I'm missing something I would greatly appreciate an explanation.
> >
> > As a result of this behavior, OJB latter materializes all the columns of
> > the table for objects which are mapped on the same table, even columns
> > that are not mapped to the object being materialized. A more detailed
> > description of the collateral damage induced by this behavior can be
> > found in a previous mail I submitted; the subject of the mail was:
> >
> > Possible bug Mapping All Classes on the Same Table
> >
> > I think a simple fix for this bug can be simply getting all mapped
> > columns for the target class descriptor instead of getting all mapped
> > columns for all the classes mapped to the same table, but I'll leave
> > this up to you experts.
> >
> > Best regards,
> > Luis Cruz
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
