There are a couple of points I'd like to add relevant to supporting polymorphic mappings.
- The VBSF kernel maintains an extends relationship for every class. It also builds various mappings which provide base class to derived class lookup when needed. This provides the ability to reference a base class and actually retrieve instances of sub classes.
- There is a performance problem with the queries on base classes. The brute force approach of firing tables x filters queries can kill performance with as little as three sub classes. This occurs mostly with queries involving non trivial joins. I don't have a general solution, but it's something to keep in mind.
- Dr. Jung alluded to mappings of a single object to multiple tables. I agree that these are not difficult to implement. The join conditions need to be added to any queries involving the class.
--Victor
Jung , Dr. Christoph wrote:
[EMAIL PROTECTED]">David, Dain, others
Currently, we use a JCA/JDO adapter built around the OR-mapper VBSF
(http://www.objectmatter.com) that supports such a thing.
I must admit that our application programmers make extensiv use of
polymorphism at this level. They do it not for accident, but for real
modelling advantages which will give us a lot of headaches when doing the
planned transition to EJB2.0. Hence before I say something technically, I
think we would be willing of dedicating resources to help with this feature
...
Interestingly, VBSF´s kernel representations (we bought the source, too;-)
are not polymorphism- or subclassing-aware. The only "advanced" things that
the kernel is able to do is to
A) spread the attributes of a class into several (id-linked) tables and join
them correctly together and
B) manage a "FILTER" attribute that fo r each entity determines the most
specific java class that the entity is an instance of (via hashcode, plain
text, or other things).
The polymorphism feature can then be added quite like decorators (or
proxies, pattern terminology is hard these days) around the "monomorphism"
implementation:
1) extent queries. Instead of querying a single "table", you want to query
all (tables x FILTER) combinations of the given class and the subclasses.
Not hard to implement when doing it over separate statements except when it
comes to ordering (which must now be done partially in-memory and
consistently with the db ordering).
2) relationships. Requires that the referenced super class has a dedicated
table (hence is not "abstract" in the db sense). When navigating, first
collect the (id´s x FILTER) of the referenced objects, then batch read the
values for each class whose FILTER has been hit.
3) queries over relationsships. Not sure here without looking at the code
again, but should work fairly trivial because you just have to verify
(id,FILTER) where FILTER is the description of a subclass of the declared
one ...
This was just quickly written and may not make total sense, maybe I´m
lacking something because I haven´t worked in the code for some month now,
but I just wanted to keep the discussion alive ;-)
CGJ
-----Ursprüngliche Nachricht-----
Von: David Jencks [mailto:[EMAIL PROTECTED]]
Gesendet: Montag, 26. August 2002 22:24
An: jboss-dev
Betreff: [JBoss-dev] Just how hard is polymorphic cmp?
I was wondering if anyone knew of any discussions of how hard it would be to
implement a "beyond the spec" cmp2 engine that allowed for polymorphism in
your entity beans.
I'm aware of Dan O'Connors article on ServerS ide, but that talks about using
a standard cmp2 engine. I'm wondering about changing the cmp2 engine
itself.
Starting such a discussion would be fine too.
Thanks
david "tired of jdo" jencks
