Hi Luis,
Luis Fernando Pollo wrote:
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.
I update/clarify repository.dtd comment and repository guide in CVS. On
next release the web-site will be updated too.
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...
Add a "wish-request" in jira.
regards,
Armin
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
