AW: AW: [JBoss-dev] Just how hard is polymorphic cmp?

[Jung , Dr. Christoph]

Title: Nachricht

Hi Victor,

 

good to see that we are not alone ;-)

 

-----Ursprüngliche Nachricht-----
Von: Victor Langelo [mailto:[EMAIL PROTECTED]]
Gesendet: Dienstag, 27. August 2002 21:13
An: [EMAIL PROTECTED]
Betreff: Re: AW: [JBoss-dev] Just how hard is polymorphic cmp?

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.  

 

Yes, I forgot to mention that. But IMHO this does not add anything "new" to the kernel, because this information could be looked up by reflection at deployment time and is there for convenience purposes. When building polymorphic structures in Queries and Relationsships as the default, with no need to look at the same entity from differently abstract "views", i.e., nodes in the class hierarchy, programmatic conversion would IMHO not be necessary (e.g., we make no use of it), but that´s certainly not generalizable.

 

 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.  

 

We havn´t yet had any serious performance problem maybe because we did not have these non-trivial joins?

 

Could you give me an example of such a three-class constellation, please? My small mind can only think of issues where trying to be smarter than brute force, hence combining the queries for several class structures into one would result in non-trivial statements that confuse the database ... Firing a set of queries instead should give you just a constant overhead, shouldn´t it?

 

The real issue could IMHO come due to a lacking indexing of the FILTER, because this attribute will be used quite frequently to clearly discriminate the separate result sets in this approach ...

 

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.

 

 The question of how hard it would be is dependent on exactly what features are required. To implement all the features of a product like VBSF would be hard. If we limit it to just allowing inheritance, it would be manageable. I haven't studied the existing cmp code yet, so I probably cannot answer David's original question.

So my conclusion was that given the last point of single-object to multiple tables (which also solves the inheritance mapping), the brute-force method which I do not find too bad as a starting point, and some restrictions on mappings for referred classes, it should not be too hard to extend an existing non-polymorphic engine without performance drawbacks for the standard mappings (without having completely looked through the cmp code in detail).  

Jung , Dr. Christoph wrote:

[EMAIL PROTECTED] type="cite">

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

###########################################

This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.F-Secure.com/