A bit of a progress on vertical inheritance. I created some unit tests
(committed, r949533) with a simple case of vertical inheritance
mapping, and after some poking around decided that we don't need to
redo all select translators from scratch (CAY-1136). The last time my
motivation for some serious refactoring was caused by the need to
support UNION queries for horizontal inheritance. With vertical we can
squeeze by with our existing code, which is actually pretty capable in
terms of adding extra columns to SELECT clause and extra joins to FROM
- all thanks to the work done for the OUTER JOIN and flattened
attributes tasks.
Locally I already have a patch that builds the right SELECT for deep
vertical inheritance fetch, just need to a few more moving parts
before I can commit it. I am doing this work under CAY-1090 Jira.
Approaches to Mapping Inheritance
---------------------------------
Currently we don't require users to specify inheritance semantics
explicitly. We guess it instead (not unlike EOF). Just select a
superclass ObjEntity and (optionally) subclass DbEntity and we'll
derive the rest. In case of vertical inheritance I wrote the code to
determine the inheritance DbRelationship out of all relationships
between the super and sub tables (1..1 PK-based relationship).
JPA for instance does require explicit inheritance semantics property
set on the superclass. Should we do the same for sanity sake? E.g. to
prevent unsupported combinations of inheritance types in a single
hierarchy. I don't know what those unsupported combinations will be at
the end (i.e. how smart our algorithms will end up being and how
extensive the test suite we'll have to say what is supported and
what's not). Having a hard rules (with validation done by the Modeler)
will make things much less ambiguous (at the expense of some
flexibility). E.g. back in the EOF days I barely used inheritance, as
it was all based on implicit mapping rules between super and
subclasses, so I never bothered to understand them (did it also
require to flatten super attributes?? My current design won't).
Thoughts on that?
Modeler
-------
Here are also a few Modeler shortcomings that I discovered when
creating the tests.
* ObjAttribute info dialog gets confused about attribute origin, so
you can't easily create super attribute overrides, or revert back to
non-overridden super. (haven't looked at the relationships yet)
* We need to decide on the basics of inheritance mapping and implement
Modeler validation based on that (see above).
Andrus
On May 19, 2010, at 11:48 AM, Andrus Adamchik wrote:
I guess right now we need to define the scope of what needs to be
done and then try to split it up.
The basic Modeler support is there in fact (so CAY-330 can probably
be closed), as you can specify both a superclass and a root table
different from superclass. So task #1 is to check how well it
actually works (is it saved/loaded correctly, does attribute/
relationships remapping work, does class generation work).
Then the backend stuff... When I looked at it last time, I started
from SelectQuery processing and I was planning to provide a
framework for handling all types of inheritance at once (as it would
suck to redo it again when we move say from h to v inheritance).
IIRC the place where I got stuck was creating (and later processing)
the right result set columns to handle a general case of inheritance
with fetching from multiple tables (tangentially related is
CAY-1141). I guess I may start by resuming this work. What makes it
harder than it should be is that we still haven't reconciled EJBQL/
SelectQuery into a single query, so there are 2 sets of translators
doing essentially the same work.
Andrus
On May 19, 2010, at 3:58 PM, Mike Kienenberger wrote:
If there is a relatively-isolated subset of the task that I can work
on in the meantime, let me know.
Perhaps some modeler/config-file support or even something more
involved in the guts.
On Wed, May 19, 2010 at 8:28 AM, Andrus Adamchik <and...@objectstyle.org
> wrote:
Hi Mike,
Would be cool to have you back :-)
Yeah, my estimate re: horizontal+vertical inheritance was that it
would
require lots of *uninterrupted* work on my end (lets say 4 weeks).
Since I
have to work on other projects at the same time, that's the luxury
I can't
afford (in fact it already resulted in a few abandoned local git
branches
where I started to develop some idea, only to realize I can't
remember what
it was when I come back to it 2 months later).
I am going to WWDC in a few weeks. Maybe I can use this "vacation"
time to
give it another shot (especially since it involves a trans-
atlantic flight
where nobody can call me or send an email ... this may be
equivalent to 4
weeks of office time :-)). I was going to work on some other 3.1
features
now, but since inheritance has always been high on my list of
things to do,
I wouldn't mind re-prioritizing...
Andrus
On May 19, 2010, at 1:19 AM, Mike Kienenberger wrote:
Andrus,
In the horizontal inheritance jira issue, you mentioned the
following:
=================
Unfortunately we dropped the ball on horizontal inheritance in
3.0 due
to the lack of time by people who could make it happen (the
implementation is rather deep and involved). I very much like to
revive this effort in 3.1 beyond a few Modeler patches that we
have in
place so far. It is in my queue right after the new DI stuff.
=================
The primary JSF/JPA team project I have been working on is now
considering switching to Cayenne and dropping JPA. One of the
concerns is vertical inheritance support. Any thoughts on how
long
it might take and how much effort is involved before vertical
inheritance is a first-class citizen? If we switch, it is likely
that I will be able to contribute toward this effort -- it was
hard to
find time to work on Cayenne when I wasn't doing any paid projects
involving Cayenne.
