Hi Armin, I'm not using the attribute myself, but I just thought it was important to clarify that the use of the attribute *does* have an effect on OBJ internally, instead of simply stating that it doesn't have any use.
The fact that it hasn't been tested doesn't mean that the it doesn't do anything and that it shouldn't be documented. My point is that it could save people time if you guys just stated clearly in the documentation what the effect of using the attribute is and then, if you see fit, directing people NOT to use the attribute at all because it leads to untested functionality. We've been through a similar discussion last year regarding the inheritance of field/collection/reference mappings from super classes because of a post of mine, and I guess everybody agreed that OJB needs some major improvements in that area, but anything serious would probably break compatibility with the current repository DTD. So I guess this is something for 1.1... Anyway, it's always good to keep these things fresh in the devel list. Luis. De:"Armin Waibel" [EMAIL PROTECTED] Para:"OJB Developers List" [email protected] Cópia: Data:Mon, 08 Aug 2005 16:46:17 +0200 Assunto:Re: Comments for the "extends" attribute of class-descriptor > Hi Luis, > > Luis Fernando Pollo wrote: > > Guys, > > > > I've read someone state in a recent post that the "extends" attribute of > > class-descriptor is not used by OJB, and assume that would be the reason > > for the lack of documentation in the repository metadata reference manual: > > > > http://db.apache.org/ojb/docu/guides/repository.html#class-descriptor-N103A6 > > > > But the truth is that it *is* used. Specifically, it's purpose is to set the > > "superClass" attribute of ClassDescriptor, which is then used in the > > getFieldDescriptorsInHeirarchy() method of that class. > > > > That method is what allows RowReaderDefaultImpl to map fields inherited from > > a superclass to a subclass, so that you don't have to create redundant > > mappings for the same properties. I think it's very important that the > > documentation be adjusted to include this information, as I've seen more > > than one question on the lists regarding the use of the "extends" attribute. > > > > The code related to attribute 'extends' is really old and not thoroughly > tested (there is no test case in ojb test-suite). Where do you use it - > with extent-class or with "super"-references (multiple joined tables...)? > > In my opinion it's not a good solution to always check in code for > inherited super-fields each time the class is used, because in code we > have always to split in if-else clause. > Furthermore each field-descriptor is associated with it's > class-descriptor, so in case of using OJB 'extent-class'-feature (don't > mix it up with the 'extends' attribute ;-)) the fields returned by > #getFieldDescriptorsInHierarchy are associated with different > class-descriptor, thus with different DB tables - I'm not sure about the > side-effects. > > I think the "inheritance of fields declared in super-classes" should be > handled by the metadata classes when reading the repository file. When > we introduce an attribute 'allowInherit' in class-descriptor and > field-descriptor element (by default it's 'true' in CLD and "undefined" > in FLD), OJB will be able to inherit copies of field-descriptor > instances to the sub-classes. > > > > B.T.W. I believe there's a typo in the name of that method... :) It should > > be getFieldDescriptorsInHierarchy. > > In that case I completely agree ;-) > > regards, > Armin > > > > > > Regards, > > > > Luis. > > > > > > > > > > --------------------------------------------------------------------- > > 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]
