Hi Luis,
Thanks for contribution.
Checked in your patch (in OJB_1_0_RELEASE branch). I made some modifications, now only RowReaderDefaultImpl was changed. Please check the new version (is it as smart as your original patch and avoid problems with field converters too?).
regards, Armin
Luis Cruz wrote:
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
