Hi All;
Over the past one and a half years ('cor, is it really one and a half?) I've
been using OJB, this is one of those niggles that has "bugged" me, but not
quite enough to do something about it.
I'm sure that proposals and patches for this feature have been sent in a few
times, and seemed to disappear into the ether.
My wish is that
a) extents inherit all field-descriptors, reference descriptors and
collection-descriptors from their parents.
b) that the extents say that they what their parent is, as opposed to the
parent saying what their children are.
This, to me, would be far more logical and map more cleanly on to the java
environment that we are all working on. Moreover, it would reduce the size
of the repository files significantly - or at least, it would for us. Our
repository is currently 12,524 lines long (each element on it's own
line)[See note at bottom]. I would estimate that "inheriting" descriptors
would reduce this by at least half. This, in turn would mean that the
repository would load a little quicker too (currently, on my relatively
hi-spec machine, usually takes around 7 seconds.)
I suspect (although I could be talking complete rubbish) that the reading of
the repository could do all this for us, without changing the internals of
the PB - something along the lines of
1. Read the repository as it is.
2. For each class-descriptor, find it's parent (if one is specified),
duplicate it's descriptors, and attach to the child, and add the child as an
extent to the parent.
It would also be possible, for those that *don't* want to have extents
inheriting, to have a boolean flag "inheritable" on
field/reference/collection-descriptors.
Is this gibberish, would it be difficult to do, and would users find this
useful ?
Cheers,
Charles.
[Note]
Just for info : this monster repository is not, as you have probably
guessed, maintained by hand. It is generated from an object model in
Rational XDE. If I could release this code to the group, I would - but we
use an XDE api that we had to sign an NDA to get access to. Anyway, the code
is pretty horrible anyway (as is the API). Suffice to say, for those that
have their object model accessible via an API - be it in Rose, XDE,
Poseidon, or in some form of XML, it is possible to generate the repository
automatically, and it saves you LOADS of time. We also generate a
torque-schema from the model, and create foreign keys in the model - the
business analysts just specify business attributes and relationships between
objects, and we work everything else out. It's just struck me, as I've
waffled away : as we generate our own repository, that is why this
"inherited" descriptors thing has never bugged me enough to make me do
something about it.
>-----Original Message-----
>From: Thomas Mahler [mailto:[EMAIL PROTECTED]
>Sent: 04 March 2003 19:38
>To: OJB Users List
>Subject: Re: automatically mapping inherited fields
>
>
>Hi Joerg,
>
>I'm not quite sure if I got your question.
>Are you asking if the field-descriptors for "name" and
>"number" must be
>present in the class-descriptors for the concrete classes, or if it is
>possible to just define them once in the base-classes descriptor?
>
>The answer to this question is: No,they have to be defined in each
>concrete classes class-descriptor!
>
>Thomas
>
>Joerg Lensing wrote:
>> hi,
>> is it possible to map "base"-fields from a base-class?
>>
>> Base-class: BaseX.class
>> fields: name, number
>>
>> (concrete) inherited classes:
>> -->ExtendedBaseX_A
>> -->ExtendedBaseX_B
>> .....|_________->ExtendedBaseX_B_xyz
>>
>> all Classes need the same fields "name" and "number". They
>allways use
>> the same
>> tablefieldnames (same and separate tables). Is there a way
>to map these
>> two fields
>> automatically to the tables?
>>
>> joerg
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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]
>
This email and any attachments are strictly confidential and are intended
solely for the addressee. If you are not the intended recipient you must
not disclose, forward, copy or take any action in reliance on this message
or its attachments. If you have received this email in error please notify
the sender as soon as possible and delete it from your computer systems.
Any views or opinions presented are solely those of the author and do not
necessarily reflect those of HPD Software Limited or its affiliates.
At present the integrity of email across the internet cannot be guaranteed
and messages sent via this medium are potentially at risk. All liability
is excluded to the extent permitted by law for any claims arising as a re-
sult of the use of this medium to transmit information by or to
HPD Software Limited or its affiliates.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
