Sorry to take so long to reply. I've been hoping for some time to review a previous project where we did encounter serious performance problems. Alas, that hasn't happened so I'll do the best I can from memory.
See my comments inline.
Jung , Dr. Christoph wrote:
[EMAIL PROTECTED]">I've found that strictly mirroring the java class hierarchy in the persistence hierarchy works well for simple class structures. However, we maintain at least two independent views of any entity. One view is used mostly for reporting purposes and often flattens out relationships (providing summary info). In practice if is very helpful to have these different views use a common base class in java code but two independent hierarchies in the persistence mapping. The point being that reflection will give the wrong result.
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.
It is possible that the only reason we've adopted this pattern is that VBSF doesn't allow attributes mapped in a super class to be remapped in derived classes. Removing this restriction might mean we could easily use the same hierarchy in both java and persistence mapping.
[EMAIL PROTECTED]">I'm not sure how to parse this sentence. Are you saying that the implementation will restrict query conditions to attributes on the base classes, consequently there is no need for the query processor to lookup derived classes? That may be true. However, VBSF doesn't have such a limit and we exceed this limit frequently.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.
[EMAIL PROTECTED]">Yes it would be a constant overhead given simple filters on table columns. Our problems came when the entity was a join of multiple tables. Some derived classes included not exists (difference) conditions. Others included outer joins. When executing queries on the base class, some conditions should have automatically eliminated queries on various sub classes. However the query optimizer did not handle this gracefully. It's not that the time for any query was different than if run independently. It's just that it the query would never have been done had we handled building the queries programmatically.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?
To make things worse, most queries on this entity had conditions on attributes of referenced entities. This required additional joins which made the optimizer's job even harder.
[EMAIL PROTECTED]">Agreed, but most databases need more than a simple index on the filter condition to optimize complex queries. This can lead to geometric growth of indices.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 ...
[EMAIL PROTECTED]">I'd agree given that it won't be the solution for everyone. My only concern is can it be extended without a major redesign.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).
[EMAIL PROTECTED]">
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 "F ILTER" 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
