Charles Anthony wrote:
Hi All;
Over the past one and a half years ('cor, is it really one and a half?)
OJB is now 2 years old and we are still fixing bugs ;-)
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.
Could be useful. But will require some changes to the metadata classes.
The current solution requires to have all information explicitely avaliable in the child-classes.
There are virtually no mechanisms to gather implicit information from superclasses right now.
b) that the extents say that they what their parent is, as opposed to the parent saying what their children are.
Same story here. for extent queries it's much simpler to do it this way then to calculate extents by traversing all known inheritance hierarchies.
It's all due to my KISS (tm) approach...
This, to me, would be far more logical and map more cleanly on to the javaI agree
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.
If your objectmodel uses a lot of inheritance, yes.
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.)
There is another mitigation to this problem: you can switch on loading a serialized version of the repository in OJB.properties. This will eliminate the parsing of repository.xml. (Well on the first start it still get's parsed...)
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.
Yes, that would be possible. But this approach has some further impact:
As the metadata layer is meant to be dynamic we must handle runtime changes of class-descriptors. So each addition, deletion or change of a class-descriptor would require a complete rescan of the repository.
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.
OK.
Is this gibberish, would it be difficult to do, and would users find this useful ?
I could imagine that it will be helpful in many cases. But I feel it will cause lots of pain for the implementors...
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.
I agree. We have developed an XMI to anything (incl. OJB repository) generator that is used for our projects.
This approach allows us to work with all UML modelling tools that can export an XMI file.
This tool currently is also closed source...
We also generate a
torque-schema from the model, and create foreign keys in the model
That's a cool idea, we currently maintain DDL manually.
- 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.
Same for us. The generator does all the tedious stuff and the developers don't have to care much about the repository details.
cheers, Thomas
-----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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
