Mailing-List: contact ojb-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "OJB Developers List" <ojb-dev@db.apache.org>
Message-ID: <40D9DB68.5060309@first.fhg.de>
Date: Wed, 23 Jun 2004 21:35:04 +0200
From: Thomas Dudziak <tomdz@first.fhg.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
MIME-Version: 1.0
To: OJB Developers List <ojb-dev@db.apache.org>
Subject: Re: How do you map a reference to an interface-backed class?
 (non-trivial)
References: <316E5B943771D311BAC500805FD7A07803431FF3@MAIL.osn.state.oh.us>
In-Reply-To: <316E5B943771D311BAC500805FD7A07803431FF3@MAIL.osn.state.oh.us>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Clute, Andrew wrote:
> Jakob, 
> 
> Yeah, I think it is a real interesting feature, as it would allow for
> exactly what you say: mapping references to objects that only share a
> common interface. Now, as for your concern, in my case it is not an
> issue since I am using GUID's as my PK, so by definition I have no PK
> collision in the extent-hierarchy. What I think you are saying though is
> to make sure that you don't map two classes where one derives from the
> other, because in that case the PK would be the same?
> 
> Thomas,
> 
> I think your idea of putting in a sub-element for the concreteClass is
> the right solution (what happens if they map more than one?). I am very
> interested in getting this feature implemented, because I have an
> immediate need for it in my project (mapping a Node Tree where objects
> in Nodes can be any one of our Business Objects). I do have some
> concerns/questions about this, and I am going to just spit them out in a
> stream:
> 
> I don't want to have to support my own version of OJB, so anything I do
> I want to make sure gets committed into the CVS tree. At the same time,
> I know that you OJB guys are going to have specific requirements for it
> to commit it. Because of that, and the fact that I have an immediate
> need for it, I want to find a way to do this right, but at the same time
> not make it take 3 months.
> 
> I am concerned that because I don't have a complete understanding of all
> the pieces of OJB (it gets better everyday), that I don't know what I am
> missing when implementing such a feature, to make it a clean, great
> implementation. I have taken a look at what I think it would take to do
> my immediate need of mapping references to interface-based objects, and
> believe I know most of the change points -- how to go about doing it. On
> the other hand, some of your other suggestions I don't really know where
> those fit in (I didn't realize that collections used the
> ojbConcreteClass stuff).

Not directly. OJB uses this field to determine which class to 
instantiate when multiple classes are mapped to the same table. This is 
independent of references/collections (it is also used when you perform 
a query against the base type but in the table is an instance of a subtype).

> So with all that, I guess what I am saying is that I am committed to
> doing this feature right, but I am not sure I can wait for all the
> features to be completed to get the one that I do need. Is this
> something that I can do in piece-meal? I am also worried about it
> conflicting with the rush of new features that will be added post-1.0.
> 
> I am looking for just a little more guidance on what this feature should
> do, to do it right, and what it touches.

I'd suggest that you start with unit tests that specify what you want to 
achieve right now as well as what could/should possibly achieved later
(btw, there is a guide for how to write unit tests against OJB and you 
can take related tests as the basis.)
This would also allow you analyze the points Jakob made and such tests 
would provide a good basis for discussion on the dev list.

Since the 1.0 is only a few days away, there will be soon a 1.1 CVS to 
work with, so these unit tests and the implementation that makes them 
pass could get into OJB pretty soon.

> With that, I have a couple of questions on your thoughts:
> 
> Do you see the concreteClassName being only used as a replacement for
> the ojbConcreteClass hard-coded fields (as in, instead of having to have
> a column defined as concreteClassName, you could define this element so
> you can have any field provide that column), or are there other
> applications for this?

They complement each other, I think. For getting rid of 
'ojbConcreteClass' it perhaps suffices to specify the field to use at 
the class-descriptor level. And a reference/collection uses this field 
in the cases where all subclasses map to the same table. If they do not 
map to the same table, then the reference/collection could specify the 
'ojbConcreteClass' value holder.

I don't know however if mixing the two mapping strategies would be 
something that a user would wish to be able to do. In that case, both 
'ojbConcreteClass' and a concreteClassName in the reference/collection 
would interact with each other.
The same might also apply when mapping inheritance hierarchies using 
multiple joined tables (using 'super' references), but I'm not really 
proficient in this.

Tom

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org