You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Mike Kienenberger <mk...@gmail.com> on 2010/05/19 00:19:53 UTC
Vertical inheritance
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.
Re: Vertical inheritance
Posted by Andrus Adamchik <an...@objectstyle.org>.
On May 31, 2010, at 7:58 AM, Mike Kienenberger wrote:
> If you're talking about the inheritance chain, JPA appears to derive
> that from the java inheritance hierarchy. It's not explicitly
> defined.
Actually I am talking about explicit inheritance strategy, not the
chain (see my other email - the chain will also be defined from the
Java structure).
Andrus
Re: Vertical inheritance
Posted by Mike Kienenberger <mk...@gmail.com>.
As I think about this a little more...
If you're talking about the inheritance chain, JPA appears to derive
that from the java inheritance hierarchy. It's not explicitly
defined.
On Mon, May 31, 2010 at 7:48 AM, Mike Kienenberger <mk...@gmail.com> wrote:
> Here's what we're using for JPA:
>
> // Contact Detail (root)
>
> @Inheritance(strategy = InheritanceType.JOINED)
> @DiscriminatorColumn(name="object_type")
> @PrimaryKeyJoinColumn(name="id", referencedColumnName="id")
>
> // Address (subclass)
>
> @DiscriminatorValue("ADR")
>
>
> I guess JPA allows another approach, which would be to specify sql for
> each subclass instead of a column value.
>
> Reviewing what's out there already for single-table inheritance (which
> I've never used before), I don't see any changes that are needed.
> Everything that works for single-table seems to be sufficient and
> necessary for vertical inheritance.
>
> As far as I can tell, the implementation difference between
> single-table and vertical is only that multiple tables are involved in
> the queries for reading and writing the data.
>
> I didn't completely understand the question, so I'm not sure if this answers it.
>
> As I read through the JPA specs, I note that it does not support mixed
> inheritance types for a set of tables as a required feature. This
> could be future work if we decided we wanted to support it.
>
> On Sun, May 30, 2010 at 1:44 PM, Andrus Adamchik <an...@objectstyle.org> wrote:
>> 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?
>
Re: Vertical inheritance
Posted by Andrus Adamchik <an...@objectstyle.org>.
Yes, multiple levels will be supported in the suggested design. All I
was saying is that the JPA-style vertical inheritance approach seems
to imply a strict single-join-table-per-subclass mapping. While with
flattened attributes, you can (theoretically) mix and match where
subclass attributes are coming from.
Andrus
On Jun 1, 2010, at 12:32 PM, Mike Kienenberger wrote:
> I'm not complete certain I understand the design -- I don't have any
> experience with single-table inheritance. It sounds ok for as much
> as I do understand. The only concern I have is that the wording
> below seems to indicate that only two tables are involved (the root
> table and the subclass table), but any vertical inheritance deeper
> than two would involve more tables (N classes deep is N tables). I'm
> 99.9% certain that you already know this, so I am certain that I'm
> just misreading your message. But I figure I better ask just in case
> I'm wrong.
>
> On Tue, Jun 1, 2010 at 9:38 AM, Andrus Adamchik <andrus@objectstyle.org
> > wrote:
>>
>> On May 31, 2010, at 9:11 AM, Andrus Adamchik wrote:
>>
>>> BTW, semantically "vertical inheritance with discriminator" is
>>> essentially
>>> single-table inheritance with flattened attributes in subclasses.
>>> Which
>>> Cayenne supports already, but without any special optimizations for
>>> wide|deep hierarchies.
>>
>> Pounding on this idea some more ... Since we can't get away from
>> using
>> entity qualifier (discriminator) at least in some cases for
>> performance
>> reasons, and I hate to add multiple strategies, maybe we do make the
>> qualifier required and treat vertical as a special case of single
>> table with
>> subclasses mapped to the same root table, and having flattened
>> attributes
>> mapped to subclass-specific table. The benefits of that are:
>>
>> * No implicit inheritance relationship from super to sub table. It is
>> explicitly mapped inside flattened attributes.
>> * More intuitive mapping, easier to visualize attributes, as all
>> attributes
>> are rooted in the same base table.
>> * Can potentially handle more than one joined table per subclass,
>> or the
>> same join table for multiple subclasses, or a mix of single table
>> mapping
>> with joined table mapping. I.e. in the spirit of Cayenne, we'd
>> allow users
>> to follow a generic DB semantics in their mapping instead of
>> forcing an
>> arbitrary ORM concepts on a (legacy) DB schema.
>> * No new concepts for the backend or Modeler to deal with.
>>
>> Now we still need to do some work with this design:
>>
>> * Make sure SELECT/INSERT/DELETE/UPDATE work correctly with flattened
>> attributes over 1..1 relationships, and especially when inheritance
>> is
>> involved.
>> * Add convenience Modeler methods to flatten all attributes at once
>> for a
>> given relationship to simplify subclass mapping.
>> * Add performance optimizations per Mike's idea, limiting the
>> number of
>> joins done in a single query.
>>
>> Mike, do you see any holes in this design?
>>
>> Cheers,
>> Andrus
>>
>>
>
Re: Vertical inheritance
Posted by Mike Kienenberger <mk...@gmail.com>.
What I probably should do is create a simple project using
single-table inheritance, point it at a relevant subset of my current
project's schema structure, and see exactly what it looks like in the
modeler and in the generated code.
On Tue, Jun 1, 2010 at 12:32 PM, Mike Kienenberger <mk...@gmail.com> wrote:
> I'm not complete certain I understand the design -- I don't have any
> experience with single-table inheritance. It sounds ok for as much
> as I do understand. The only concern I have is that the wording
> below seems to indicate that only two tables are involved (the root
> table and the subclass table), but any vertical inheritance deeper
> than two would involve more tables (N classes deep is N tables). I'm
> 99.9% certain that you already know this, so I am certain that I'm
> just misreading your message. But I figure I better ask just in case
> I'm wrong.
>
> On Tue, Jun 1, 2010 at 9:38 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
>>
>> On May 31, 2010, at 9:11 AM, Andrus Adamchik wrote:
>>
>>> BTW, semantically "vertical inheritance with discriminator" is essentially
>>> single-table inheritance with flattened attributes in subclasses. Which
>>> Cayenne supports already, but without any special optimizations for
>>> wide|deep hierarchies.
>>
>> Pounding on this idea some more ... Since we can't get away from using
>> entity qualifier (discriminator) at least in some cases for performance
>> reasons, and I hate to add multiple strategies, maybe we do make the
>> qualifier required and treat vertical as a special case of single table with
>> subclasses mapped to the same root table, and having flattened attributes
>> mapped to subclass-specific table. The benefits of that are:
>>
>> * No implicit inheritance relationship from super to sub table. It is
>> explicitly mapped inside flattened attributes.
>> * More intuitive mapping, easier to visualize attributes, as all attributes
>> are rooted in the same base table.
>> * Can potentially handle more than one joined table per subclass, or the
>> same join table for multiple subclasses, or a mix of single table mapping
>> with joined table mapping. I.e. in the spirit of Cayenne, we'd allow users
>> to follow a generic DB semantics in their mapping instead of forcing an
>> arbitrary ORM concepts on a (legacy) DB schema.
>> * No new concepts for the backend or Modeler to deal with.
>>
>> Now we still need to do some work with this design:
>>
>> * Make sure SELECT/INSERT/DELETE/UPDATE work correctly with flattened
>> attributes over 1..1 relationships, and especially when inheritance is
>> involved.
>> * Add convenience Modeler methods to flatten all attributes at once for a
>> given relationship to simplify subclass mapping.
>> * Add performance optimizations per Mike's idea, limiting the number of
>> joins done in a single query.
>>
>> Mike, do you see any holes in this design?
>>
>> Cheers,
>> Andrus
>>
>>
>
Re: Vertical inheritance
Posted by Mike Kienenberger <mk...@gmail.com>.
I'm not complete certain I understand the design -- I don't have any
experience with single-table inheritance. It sounds ok for as much
as I do understand. The only concern I have is that the wording
below seems to indicate that only two tables are involved (the root
table and the subclass table), but any vertical inheritance deeper
than two would involve more tables (N classes deep is N tables). I'm
99.9% certain that you already know this, so I am certain that I'm
just misreading your message. But I figure I better ask just in case
I'm wrong.
On Tue, Jun 1, 2010 at 9:38 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
>
> On May 31, 2010, at 9:11 AM, Andrus Adamchik wrote:
>
>> BTW, semantically "vertical inheritance with discriminator" is essentially
>> single-table inheritance with flattened attributes in subclasses. Which
>> Cayenne supports already, but without any special optimizations for
>> wide|deep hierarchies.
>
> Pounding on this idea some more ... Since we can't get away from using
> entity qualifier (discriminator) at least in some cases for performance
> reasons, and I hate to add multiple strategies, maybe we do make the
> qualifier required and treat vertical as a special case of single table with
> subclasses mapped to the same root table, and having flattened attributes
> mapped to subclass-specific table. The benefits of that are:
>
> * No implicit inheritance relationship from super to sub table. It is
> explicitly mapped inside flattened attributes.
> * More intuitive mapping, easier to visualize attributes, as all attributes
> are rooted in the same base table.
> * Can potentially handle more than one joined table per subclass, or the
> same join table for multiple subclasses, or a mix of single table mapping
> with joined table mapping. I.e. in the spirit of Cayenne, we'd allow users
> to follow a generic DB semantics in their mapping instead of forcing an
> arbitrary ORM concepts on a (legacy) DB schema.
> * No new concepts for the backend or Modeler to deal with.
>
> Now we still need to do some work with this design:
>
> * Make sure SELECT/INSERT/DELETE/UPDATE work correctly with flattened
> attributes over 1..1 relationships, and especially when inheritance is
> involved.
> * Add convenience Modeler methods to flatten all attributes at once for a
> given relationship to simplify subclass mapping.
> * Add performance optimizations per Mike's idea, limiting the number of
> joins done in a single query.
>
> Mike, do you see any holes in this design?
>
> Cheers,
> Andrus
>
>
Re: Vertical inheritance
Posted by Andrus Adamchik <an...@objectstyle.org>.
Hi Lachlan,
thanks for the feedback. I think I'll be moving ahead with this design
(and I wish I had more time for Cayenne work in general)...
Andrus
On Jun 2, 2010, at 10:43 PM, Lachlan Deck wrote:
> On 01/06/2010, at 11:38 PM, Andrus Adamchik wrote:
>
>> On May 31, 2010, at 9:11 AM, Andrus Adamchik wrote:
>>
>>> BTW, semantically "vertical inheritance with discriminator" is
>>> essentially single-table inheritance with flattened attributes in
>>> subclasses. Which Cayenne supports already, but without any
>>> special optimizations for wide|deep hierarchies.
>>
>> Pounding on this idea some more ... Since we can't get away from
>> using entity qualifier (discriminator) at least in some cases for
>> performance reasons, and I hate to add multiple strategies, maybe
>> we do make the qualifier required and treat vertical as a special
>> case of single table with subclasses mapped to the same root table,
>> and having flattened attributes mapped to subclass-specific table.
>> The benefits of that are:
>>
>> * No implicit inheritance relationship from super to sub table. It
>> is explicitly mapped inside flattened attributes.
>> * More intuitive mapping, easier to visualize attributes, as all
>> attributes are rooted in the same base table.
>> * Can potentially handle more than one joined table per subclass,
>> or the same join table for multiple subclasses, or a mix of single
>> table mapping with joined table mapping. I.e. in the spirit of
>> Cayenne, we'd allow users to follow a generic DB semantics in their
>> mapping instead of forcing an arbitrary ORM concepts on a (legacy)
>> DB schema.
>> * No new concepts for the backend or Modeler to deal with.
>
> +1
>
>> Now we still need to do some work with this design:
>>
>> * Make sure SELECT/INSERT/DELETE/UPDATE work correctly with
>> flattened attributes over 1..1 relationships, and especially when
>> inheritance is involved.
>> * Add convenience Modeler methods to flatten all attributes at once
>> for a given relationship to simplify subclass mapping.
>> * Add performance optimizations per Mike's idea, limiting the
>> number of joins done in a single query.
>>
>> Mike, do you see any holes in this design?
>
> Looks good.
>
> with regards,
> --
>
> Lachlan Deck
>
>
Re: Vertical inheritance
Posted by Lachlan Deck <la...@gmail.com>.
On 01/06/2010, at 11:38 PM, Andrus Adamchik wrote:
> On May 31, 2010, at 9:11 AM, Andrus Adamchik wrote:
>
>> BTW, semantically "vertical inheritance with discriminator" is essentially single-table inheritance with flattened attributes in subclasses. Which Cayenne supports already, but without any special optimizations for wide|deep hierarchies.
>
> Pounding on this idea some more ... Since we can't get away from using entity qualifier (discriminator) at least in some cases for performance reasons, and I hate to add multiple strategies, maybe we do make the qualifier required and treat vertical as a special case of single table with subclasses mapped to the same root table, and having flattened attributes mapped to subclass-specific table. The benefits of that are:
>
> * No implicit inheritance relationship from super to sub table. It is explicitly mapped inside flattened attributes.
> * More intuitive mapping, easier to visualize attributes, as all attributes are rooted in the same base table.
> * Can potentially handle more than one joined table per subclass, or the same join table for multiple subclasses, or a mix of single table mapping with joined table mapping. I.e. in the spirit of Cayenne, we'd allow users to follow a generic DB semantics in their mapping instead of forcing an arbitrary ORM concepts on a (legacy) DB schema.
> * No new concepts for the backend or Modeler to deal with.
+1
> Now we still need to do some work with this design:
>
> * Make sure SELECT/INSERT/DELETE/UPDATE work correctly with flattened attributes over 1..1 relationships, and especially when inheritance is involved.
> * Add convenience Modeler methods to flatten all attributes at once for a given relationship to simplify subclass mapping.
> * Add performance optimizations per Mike's idea, limiting the number of joins done in a single query.
>
> Mike, do you see any holes in this design?
Looks good.
with regards,
--
Lachlan Deck
Re: Vertical inheritance
Posted by Andrus Adamchik <an...@objectstyle.org>.
On May 31, 2010, at 9:11 AM, Andrus Adamchik wrote:
> BTW, semantically "vertical inheritance with discriminator" is
> essentially single-table inheritance with flattened attributes in
> subclasses. Which Cayenne supports already, but without any special
> optimizations for wide|deep hierarchies.
Pounding on this idea some more ... Since we can't get away from using
entity qualifier (discriminator) at least in some cases for
performance reasons, and I hate to add multiple strategies, maybe we
do make the qualifier required and treat vertical as a special case of
single table with subclasses mapped to the same root table, and having
flattened attributes mapped to subclass-specific table. The benefits
of that are:
* No implicit inheritance relationship from super to sub table. It is
explicitly mapped inside flattened attributes.
* More intuitive mapping, easier to visualize attributes, as all
attributes are rooted in the same base table.
* Can potentially handle more than one joined table per subclass, or
the same join table for multiple subclasses, or a mix of single table
mapping with joined table mapping. I.e. in the spirit of Cayenne, we'd
allow users to follow a generic DB semantics in their mapping instead
of forcing an arbitrary ORM concepts on a (legacy) DB schema.
* No new concepts for the backend or Modeler to deal with.
Now we still need to do some work with this design:
* Make sure SELECT/INSERT/DELETE/UPDATE work correctly with flattened
attributes over 1..1 relationships, and especially when inheritance is
involved.
* Add convenience Modeler methods to flatten all attributes at once
for a given relationship to simplify subclass mapping.
* Add performance optimizations per Mike's idea, limiting the number
of joins done in a single query.
Mike, do you see any holes in this design?
Cheers,
Andrus
Re: Vertical inheritance
Posted by Lachlan Deck <la...@gmail.com>.
On 31/05/2010, at 11:11 PM, Andrus Adamchik wrote:
> Good thoughts. I really like the adaptive strategy idea, which can probably be used for discriminator-free vertical mapping as well.
I'm not sure about this though: at what point would a user need to start adding the discriminator to their historic data? How would they go about it? It sounds like you'd need to stick with a strategy from the start.
(It certainly makes looking at data via sql easier with a discriminator too :)
> BTW, semantically "vertical inheritance with discriminator" is essentially single-table inheritance with flattened attributes in subclasses. Which Cayenne supports already, but without any special optimizations for wide|deep hierarchies.
>> On Mon, May 31, 2010 at 8:29 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
>>> Great. this is the kind of feedback I was looking for :-)
>>>
>>> On May 31, 2010, at 8:17 AM, Mike Kienenberger wrote:
>>>> What you're suggesting could work, but we have at least one very deep
>>>> and wide inheritance tree in our current app, and the performance hit
>>>> of joining more than a hundred tables (so far) unnecessarily would
>>>> kill us.
>>>
>>> So how would you do a fetch based on discriminator column approach? I can
>>> think of a 2 step process:
>>>
>>> 1. Fetch ID's + discriminator columns from the root table.
>>> 2. Fully resolve objects, either doing joins only for the subset of tables
>>> that appeared in result in #1, or doing a separate query (without joins) for
>>> each subclass table matching the set of IDs.
>>>
>>> Does that sound right?
Yep.
>>> Also I am sort of in favor of my original discriminator-free approach for
>>> smaller hierarchies, so wonder if a fetch strategy can be something
>>> specified for a given super-entity and/or query.
The discriminator-free approach sounds more complex to achieve for the initial cut though maybe?
with regards,
--
Lachlan Deck
Re: Vertical inheritance
Posted by Andrus Adamchik <an...@objectstyle.org>.
Good thoughts. I really like the adaptive strategy idea, which can
probably be used for discriminator-free vertical mapping as well.
BTW, semantically "vertical inheritance with discriminator" is
essentially single-table inheritance with flattened attributes in
subclasses. Which Cayenne supports already, but without any special
optimizations for wide|deep hierarchies.
Andrus
On May 31, 2010, at 9:01 AM, Mike Kienenberger wrote:
> I'm not sure how deep our worse-case tree is, but we probably could
> get by with joining all tables. It's really the width of the tree
> that would prohibit joining everything. I agree that using an outer
> join on all tables be more performant for certain types of tables with
> small numbers of tables -- this is the case for most of our vertical
> inheritance -- five to ten tables, and I like the idea of being able
> to do so.
>
> We should probably come up with some kind of limit on how many tables
> (or maybe columns) we want to fetch at one time, and then try to pick
> the right strategy based on that. I'd say that we would try to
> always maximize the amount of data pulled in for each strategy.
>
> So it sounds right to me. I'd say we'd want to avoid the "without
> joins" query as much as possible.
>
> Do we need to fetch the id/discriminator from the root table as a
> separate query? I guess we do for the cases where we're not fetching
> a leaf class. But for a leaf class, we could fetch all records in
> one query.
>
> I suppose we should start with the worse-case scenario and that will
> cover every other type of query as a first pass.
>
> I see that as
>
> 1) fetch the root table to determine the discriminator value.
> (subclass unknown worse case)
> 2) fetch each sub table individually (depth too large worse case)
>
> Then we could consider optimizations:
>
> a) leaf subclass is known -- one query can fetch root and subtables if
> depth is not too deep
> b) depth is small -- one query can fetch all subtables (and possibly
> root if leaf subclass)
> c) total tables involved is small -- can do an outer join of all
> tables and sort things out in memory
>
> I didn't realize how complicated this was going to get :)
>
> I think it's probably a good idea to be able to specify a fetch
> strategy, at least at first -- might be needed to get around
> limitations or bugs in our fetch strategies. But I think we should
> also be able to derive a best-case fetch strategy based on the model
> as well.
>
> On Mon, May 31, 2010 at 8:29 AM, Andrus Adamchik <andrus@objectstyle.org
> > wrote:
>> Great. this is the kind of feedback I was looking for :-)
>>
>> On May 31, 2010, at 8:17 AM, Mike Kienenberger wrote:
>>>
>>> What you're suggesting could work, but we have at least one very
>>> deep
>>> and wide inheritance tree in our current app, and the performance
>>> hit
>>> of joining more than a hundred tables (so far) unnecessarily would
>>> kill us.
>>
>> So how would you do a fetch based on discriminator column approach?
>> I can
>> think of a 2 step process:
>>
>> 1. Fetch ID's + discriminator columns from the root table.
>> 2. Fully resolve objects, either doing joins only for the subset of
>> tables
>> that appeared in result in #1, or doing a separate query (without
>> joins) for
>> each subclass table matching the set of IDs.
>>
>> Does that sound right?
>>
>> Also I am sort of in favor of my original discriminator-free
>> approach for
>> smaller hierarchies, so wonder if a fetch strategy can be something
>> specified for a given super-entity and/or query.
>>
>> Andrus
>>
>>
>
Re: Vertical inheritance
Posted by Mike Kienenberger <mk...@gmail.com>.
I'm not sure how deep our worse-case tree is, but we probably could
get by with joining all tables. It's really the width of the tree
that would prohibit joining everything. I agree that using an outer
join on all tables be more performant for certain types of tables with
small numbers of tables -- this is the case for most of our vertical
inheritance -- five to ten tables, and I like the idea of being able
to do so.
We should probably come up with some kind of limit on how many tables
(or maybe columns) we want to fetch at one time, and then try to pick
the right strategy based on that. I'd say that we would try to
always maximize the amount of data pulled in for each strategy.
So it sounds right to me. I'd say we'd want to avoid the "without
joins" query as much as possible.
Do we need to fetch the id/discriminator from the root table as a
separate query? I guess we do for the cases where we're not fetching
a leaf class. But for a leaf class, we could fetch all records in
one query.
I suppose we should start with the worse-case scenario and that will
cover every other type of query as a first pass.
I see that as
1) fetch the root table to determine the discriminator value.
(subclass unknown worse case)
2) fetch each sub table individually (depth too large worse case)
Then we could consider optimizations:
a) leaf subclass is known -- one query can fetch root and subtables if
depth is not too deep
b) depth is small -- one query can fetch all subtables (and possibly
root if leaf subclass)
c) total tables involved is small -- can do an outer join of all
tables and sort things out in memory
I didn't realize how complicated this was going to get :)
I think it's probably a good idea to be able to specify a fetch
strategy, at least at first -- might be needed to get around
limitations or bugs in our fetch strategies. But I think we should
also be able to derive a best-case fetch strategy based on the model
as well.
On Mon, May 31, 2010 at 8:29 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
> Great. this is the kind of feedback I was looking for :-)
>
> On May 31, 2010, at 8:17 AM, Mike Kienenberger wrote:
>>
>> What you're suggesting could work, but we have at least one very deep
>> and wide inheritance tree in our current app, and the performance hit
>> of joining more than a hundred tables (so far) unnecessarily would
>> kill us.
>
> So how would you do a fetch based on discriminator column approach? I can
> think of a 2 step process:
>
> 1. Fetch ID's + discriminator columns from the root table.
> 2. Fully resolve objects, either doing joins only for the subset of tables
> that appeared in result in #1, or doing a separate query (without joins) for
> each subclass table matching the set of IDs.
>
> Does that sound right?
>
> Also I am sort of in favor of my original discriminator-free approach for
> smaller hierarchies, so wonder if a fetch strategy can be something
> specified for a given super-entity and/or query.
>
> Andrus
>
>
Re: Vertical inheritance
Posted by Andrus Adamchik <an...@objectstyle.org>.
Great. this is the kind of feedback I was looking for :-)
On May 31, 2010, at 8:17 AM, Mike Kienenberger wrote:
> What you're suggesting could work, but we have at least one very deep
> and wide inheritance tree in our current app, and the performance hit
> of joining more than a hundred tables (so far) unnecessarily would
> kill us.
So how would you do a fetch based on discriminator column approach? I
can think of a 2 step process:
1. Fetch ID's + discriminator columns from the root table.
2. Fully resolve objects, either doing joins only for the subset of
tables that appeared in result in #1, or doing a separate query
(without joins) for each subclass table matching the set of IDs.
Does that sound right?
Also I am sort of in favor of my original discriminator-free approach
for smaller hierarchies, so wonder if a fetch strategy can be
something specified for a given super-entity and/or query.
Andrus
Re: Vertical inheritance
Posted by Mike Kienenberger <mk...@gmail.com>.
I guess I'd prefer to at least have the ability to do explicit
mapping, like the modeler currently supports for single-table.
What you're suggesting could work, but we have at least one very deep
and wide inheritance tree in our current app, and the performance hit
of joining more than a hundred tables (so far) unnecessarily would
kill us.
On Mon, May 31, 2010 at 8:00 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
>
> On May 31, 2010, at 7:48 AM, Mike Kienenberger wrote:
>
>> I didn't completely understand the question, so I'm not sure if this
>> answers it.
>
> I guess the question was whether we want this in Cayenne mapping in some
> form:
>
> @Inheritance(strategy = InheritanceType.JOINED)
>
> or guess the strategy from other mapping clues (the later is our current
> approach). It was more of a discussion item on what are the benefits of
> either approach.
>
>> @DiscriminatorColumn(name="object_type")
>
> Actually my plan is to use OUTER joins in Cayenne SELECT queries, so entity
> type will be determined from the presence of the non-null joined ID column
> in the result set and explicit discriminator ("entity qualifier expression"
> in Cayenne terms) won't be needed.
>
> Andrus
>
>
Re: Vertical inheritance
Posted by Andrus Adamchik <an...@objectstyle.org>.
On May 31, 2010, at 7:48 AM, Mike Kienenberger wrote:
> I didn't completely understand the question, so I'm not sure if this
> answers it.
I guess the question was whether we want this in Cayenne mapping in
some form:
@Inheritance(strategy = InheritanceType.JOINED)
or guess the strategy from other mapping clues (the later is our
current approach). It was more of a discussion item on what are the
benefits of either approach.
> @DiscriminatorColumn(name="object_type")
Actually my plan is to use OUTER joins in Cayenne SELECT queries, so
entity type will be determined from the presence of the non-null
joined ID column in the result set and explicit discriminator ("entity
qualifier expression" in Cayenne terms) won't be needed.
Andrus
Re: Vertical inheritance
Posted by Mike Kienenberger <mk...@gmail.com>.
Here's what we're using for JPA:
// Contact Detail (root)
@Inheritance(strategy = InheritanceType.JOINED)
@DiscriminatorColumn(name="object_type")
@PrimaryKeyJoinColumn(name="id", referencedColumnName="id")
// Address (subclass)
@DiscriminatorValue("ADR")
I guess JPA allows another approach, which would be to specify sql for
each subclass instead of a column value.
Reviewing what's out there already for single-table inheritance (which
I've never used before), I don't see any changes that are needed.
Everything that works for single-table seems to be sufficient and
necessary for vertical inheritance.
As far as I can tell, the implementation difference between
single-table and vertical is only that multiple tables are involved in
the queries for reading and writing the data.
I didn't completely understand the question, so I'm not sure if this answers it.
As I read through the JPA specs, I note that it does not support mixed
inheritance types for a set of tables as a required feature. This
could be future work if we decided we wanted to support it.
On Sun, May 30, 2010 at 1:44 PM, Andrus Adamchik <an...@objectstyle.org> wrote:
> 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?
Re: Vertical inheritance
Posted by Andrus Adamchik <an...@objectstyle.org>.
I suspected it all along - Cayenne 3.0 fully supports vertical
inheritance, and we didn't even know that ourselves :-)
I just wrote a few tests using "single table inheritance with
flattened attributes" approach. All of them passed without changing a
single line of code in Cayenne. I am still going to test attribute
overrides, and maybe a few odd relationship scenarios and we may need
that performance optimization patch to scale to hundreds of
subclasses, but... it just works the way it is.
Looks like we have a killer new feature to announce in 3.0.1 ;-)
Andrus
Re: Vertical inheritance
Posted by Andrus Adamchik <an...@objectstyle.org>.
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 <andrus@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.
>>>>
>>>
>>>
>>
>
>
Re: Vertical inheritance
Posted by Andrus Adamchik <an...@objectstyle.org>.
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 <andrus@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.
>>>
>>
>>
>
Re: Vertical inheritance
Posted by Mike Kienenberger <mk...@gmail.com>.
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 <an...@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.
>>
>
>
Re: Vertical inheritance
Posted by Julia Filho <jf...@yahoo.com>.
Hi Andrus,
Thanks for your help on this. We have decided, though, to use single
inheritance in this situation due to
performance concerns (want to minimize joins).
If we do use vertical inheritance in the future, I will let you know of
anything interesting (or challenging) we find.
thanks again,
Julie Filho
--
View this message in context: http://cayenne.195.n3.nabble.com/Vertical-inheritance-tp827636p1372064.html
Sent from the Cayenne - Dev mailing list archive at Nabble.com.
Re: Vertical inheritance
Posted by Andrus Adamchik <an...@objectstyle.org>.
Hi Julia,
With a bit of tweaking of the model I was able to get a query like that:
SELECT t0.LAST_MODIFIED_TIME, t0.COLLECTION_TYPE_ID, t0.AUTO_OPEN_DATE, t0.SNAPSHOT_DATE, t0.DESCRIPTION, t0.SUPT_APPROVAL_REQD, t0.LAST_MODIFIED_BY, t0.ACTIVE_IND, t0.AUTO_CLOSE_DATE, t0.COLLECTION_NAME, t1.SCHOOL_YEAR, t0.DATA_COLLECTION_ID FROM ESDM.DATA_COLLECTION t0 LEFT JOIN ESDM.K12_DATA_COLLECTION t1 ON (t0.DATA_COLLECTION_ID = t1.DATA_COLLECTION_ID) WHERE t0.COLLECTION_TYPE_ID = ? [bind: 1->COLLECTION_TYPE_ID:3]
A few things that I changed:
* Removed explicit "Table" mapping from subclass. I.e.
<obj-entity name="K12DataCollection" className="com.escholar.datamgr.model.K12DataCollection" dbEntityName="K12_DATA_COLLECTION">
Should be
<obj-entity name="K12DataCollection" className="com.escholar.datamgr.model.K12DataCollection">
Even though the table is the same as superclass, it seemed to confuse Cayenne. I will open a Jira to add a validation check for this condition.
* There was a warning in your DataMap about DataCollection.k12DataCollection ObjRelationship. So I removed it as it is uneeded. (DbRelationship should stay though).
Let me know if you have further questions. Vertical inheritance is a fairly recent addition to Cayenne, so we may not catch/handle all deviations from the standard mapping. You feedback is very helpful in this regard.
Cheers,
Andrus
On Aug 25, 2010, at 7:10 PM, Julia Filho wrote:
>
> Hi,
>
> Is vertical inheritance not supported in Cayenne 3.0? According to the
> documentation, vertical inheritance is supported, but I am running into
> problems with the generated SELECT query when reading one of the subclasses:
>
> The generated query is:
>
> SELECT t0.DATA_COLLECTION_ID, t0.COLLECTION_TYPE_ID, t0.DATA_COLLECTION_ID,
> t0.SCHOOL_YEAR, t0.SNAPSHOT_DATE FROM ESDM.K12_DATA_COLLECTION t0 JOIN
> ESDM.DATA_COLLECTION t1 ON (t0.DATA_COLLECTION_ID = t1.DATA_COLLECTION_ID)
> JOIN ESDM.DATA_COLLECTION_TYPE t2 ON (t1.COLLECTION_TYPE_ID =
> t2.COLLECTION_TYPE_ID) WHERE t2.COLLECTION_TYPE_ID = ? [bind:
> 1->COLLECTION_TYPE_ID:3]
>
>
> which is a problem because
> 1) column COLLECTION_TYPE_ID is in select list for the subclass
> (K12_DATA_COLLECTION) but that column is in the super class table
> (DATA_COLLECTION), not the subclass
> 2) DATA_COLLECTION_ID is in the K12_DATA_COLLECTION select list twice.
>
> Do you have any suggestions, or is this functionality not yet supported?
>
> thank you for any assistance you can give
> Julie
>
>
> --
> View this message in context: http://cayenne.195.n3.nabble.com/Vertical-inheritance-tp827636p1334340.html
> Sent from the Cayenne - Dev mailing list archive at Nabble.com.
>
Re: Vertical inheritance
Posted by Julia Filho <jf...@yahoo.com>.
One thing to note (and this is the kind of thing that happens when you start
trying alot of things to get something to work) is that the DATA_COLLECTION
table now has the attributes that I want to have in the K12_DATA_COLLECTION
because I am in the process of trying Single Table inheritance, and the
mapping is part way there. The fact is, though, that the generated SELECT
query is the same in that it is referencing COLLECTION_TYPE_ID in
K12_DATA_COLLECTION.
again - thanks for your help and sorry for the barrage of posts
Julie
Julia Filho wrote:
>
> Hi,
>
> Please disregard my previous post - those mappings were from the wrong
> mapping file. These are the mappings I am using:
>
> <db-entity name="DATA_COLLECTION" schema="ESDM">
> <db-attribute name="ACTIVE_IND" type="CHAR" isMandatory="true"
> length="1"/>
> <db-attribute name="AUTO_CLOSE_DATE" type="TIMESTAMP" length="7"/>
> <db-attribute name="AUTO_OPEN_DATE" type="TIMESTAMP" length="7"/>
> <db-attribute name="COLLECTION_NAME" type="VARCHAR" isMandatory="true"
> length="255"/>
> <db-attribute name="COLLECTION_TYPE_ID" type="INTEGER"
> isMandatory="true" length="22"/>
> <db-attribute name="DATA_COLLECTION_ID" type="INTEGER"
> isPrimaryKey="true" isMandatory="true" length="22"/>
> <db-attribute name="DESCRIPTION" type="VARCHAR" isMandatory="true"
> length="255"/>
> <db-attribute name="LAST_MODIFIED_BY" type="VARCHAR" isMandatory="true"
> length="20"/>
> <db-attribute name="LAST_MODIFIED_TIME" type="TIMESTAMP"
> isMandatory="true" length="11"/>
> <db-attribute name="SCHOOL_YEAR" type="TIMESTAMP" length="7"/>
> <db-attribute name="SNAPSHOT_DATE" type="TIMESTAMP" length="7"/>
> <db-attribute name="SUPT_APPROVAL_REQD" type="CHAR" isMandatory="true"
> length="1"/>
> </db-entity>
>
>
> <db-entity name="K12_DATA_COLLECTION" schema="ESDM">
> <db-attribute name="DATA_COLLECTION_ID" type="INTEGER"
> isPrimaryKey="true" isMandatory="true" length="22"/>
> <db-attribute name="SCHOOL_YEAR" type="TIMESTAMP" isMandatory="true"
> length="7"/>
> <db-attribute name="SNAPSHOT_DATE" type="TIMESTAMP" isMandatory="true"
> length="7"/>
> </db-entity>
>
> <db-entity name="DATA_COLLECTION_TYPE" schema="ESDM">
> <db-attribute name="COLLECTION_TYPE_DESC" type="VARCHAR" length="255"/>
> <db-attribute name="COLLECTION_TYPE_ID" type="INTEGER"
> isPrimaryKey="true" isMandatory="true" length="22"/>
> <db-attribute name="COLLECTION_TYPE_NAME" type="VARCHAR"
> isMandatory="true" length="20"/>
> </db-entity>
>
>
>
> <obj-entity name="DataCollection"
> className="com.escholar.datamgr.model.DataCollection"
> dbEntityName="DATA_COLLECTION">
> <obj-attribute name="activeInd" type="java.lang.String"
> db-attribute-path="ACTIVE_IND"/>
> <obj-attribute name="autoCloseDate" type="java.util.Date"
> db-attribute-path="AUTO_CLOSE_DATE"/>
> <obj-attribute name="autoOpenDate" type="java.util.Date"
> db-attribute-path="AUTO_OPEN_DATE"/>
> <obj-attribute name="collectionName" type="java.lang.String"
> db-attribute-path="COLLECTION_NAME"/>
> <obj-attribute name="description" type="java.lang.String"
> db-attribute-path="DESCRIPTION"/>
> <obj-attribute name="lastModifiedBy" type="java.lang.String"
> db-attribute-path="LAST_MODIFIED_BY"/>
> <obj-attribute name="lastModifiedTime" type="java.util.Date"
> db-attribute-path="LAST_MODIFIED_TIME"/>
> <obj-attribute name="schoolYear" type="java.util.Date"
> db-attribute-path="SCHOOL_YEAR"/>
> <obj-attribute name="snapshotDate" type="java.util.Date"
> db-attribute-path="SNAPSHOT_DATE"/>
> <obj-attribute name="suptApprovalReqd" type="java.lang.String"
> db-attribute-path="SUPT_APPROVAL_REQD"/>
> </obj-entity>
> <obj-entity name="K12DataCollection" superEntityName="DataCollection"
> className="com.escholar.datamgr.model.K12DataCollection"
> dbEntityName="DATA_COLLECTION">
> <qualifier><![CDATA[collectionTypeId = 3]]></qualifier>
> <obj-attribute name="schoolYear" type="java.util.Date"
> db-attribute-path="SCHOOL_YEAR"/>
> <obj-attribute name="snapshotDate" type="java.util.Date"
> db-attribute-path="SNAPSHOT_DATE"/>
> </obj-entity>
>
> <obj-entity name="DataCollectionType"
> className="com.escholar.datamgr.model.DataCollectionType"
> dbEntityName="DATA_COLLECTION_TYPE">
> <obj-attribute name="collectionTypeDesc" type="java.lang.String"
> db-attribute-path="COLLECTION_TYPE_DESC"/>
> <obj-attribute name="collectionTypeId" type="java.lang.Integer"
> db-attribute-path="COLLECTION_TYPE_ID"/>
> <obj-attribute name="collectionTypeName" type="java.lang.String"
> db-attribute-path="COLLECTION_TYPE_NAME"/>
> </obj-entity>
>
>
> <db-relationship name="k12DataCollection" source="DATA_COLLECTION"
> target="K12_DATA_COLLECTION" toDependentPK="true" toMany="false">
> <db-attribute-pair source="DATA_COLLECTION_ID"
> target="DATA_COLLECTION_ID"/>
> </db-relationship>
>
> <db-relationship name="dataCollection" source="K12_DATA_COLLECTION"
> target="DATA_COLLECTION" toMany="false">
> <db-attribute-pair source="DATA_COLLECTION_ID"
> target="DATA_COLLECTION_ID"/>
> </db-relationship>
>
> <db-relationship name="collectionType" source="DATA_COLLECTION"
> target="DATA_COLLECTION_TYPE" toMany="false">
> <db-attribute-pair source="COLLECTION_TYPE_ID"
> target="COLLECTION_TYPE_ID"/>
> </db-relationship>
>
> <db-relationship name="dataCollections" source="DATA_COLLECTION_TYPE"
> target="DATA_COLLECTION" toMany="true">
> <db-attribute-pair source="COLLECTION_TYPE_ID"
> target="COLLECTION_TYPE_ID"/>
> </db-relationship>
>
>
> <obj-relationship name="collectionType" source="DataCollection"
> target="DataCollectionType" deleteRule="Nullify"
> db-relationship-path="collectionType"/>
>
> <obj-relationship name="k12DataCollection" source="DataCollection"
> target="K12DataCollection" deleteRule="Nullify"
> db-relationship-path="k12DataCollection"/>
>
> <obj-relationship name="dataCollections" source="DataCollectionType"
> target="DataCollection" deleteRule="Deny"
> db-relationship-path="dataCollections"/>
>
>
> I apologize for the confusion.
>
> thanks again,
> Julie
>
>
>
> <db-relationship name="dataCollections" source="DATA_COLLECTION_TYPE"
> target="DATA_COLLECTION" toMany="true">
> <db-attribute-pair source="COLLECTION_TYPE_ID"
> target="COLLECTION_TYPE_ID"/>
> </db-relationship>
>
--
View this message in context: http://cayenne.195.n3.nabble.com/Vertical-inheritance-tp827636p1353524.html
Sent from the Cayenne - Dev mailing list archive at Nabble.com.
Re: Vertical inheritance
Posted by Julia Filho <jf...@yahoo.com>.
Hi,
Please disregard my previous post - those mappings were from the wrong
mapping file. These are the mappings I am using:
<db-entity name="DATA_COLLECTION" schema="ESDM">
<db-attribute name="ACTIVE_IND" type="CHAR" isMandatory="true"
length="1"/>
<db-attribute name="AUTO_CLOSE_DATE" type="TIMESTAMP" length="7"/>
<db-attribute name="AUTO_OPEN_DATE" type="TIMESTAMP" length="7"/>
<db-attribute name="COLLECTION_NAME" type="VARCHAR" isMandatory="true"
length="255"/>
<db-attribute name="COLLECTION_TYPE_ID" type="INTEGER" isMandatory="true"
length="22"/>
<db-attribute name="DATA_COLLECTION_ID" type="INTEGER" isPrimaryKey="true"
isMandatory="true" length="22"/>
<db-attribute name="DESCRIPTION" type="VARCHAR" isMandatory="true"
length="255"/>
<db-attribute name="LAST_MODIFIED_BY" type="VARCHAR" isMandatory="true"
length="20"/>
<db-attribute name="LAST_MODIFIED_TIME" type="TIMESTAMP"
isMandatory="true" length="11"/>
<db-attribute name="SCHOOL_YEAR" type="TIMESTAMP" length="7"/>
<db-attribute name="SNAPSHOT_DATE" type="TIMESTAMP" length="7"/>
<db-attribute name="SUPT_APPROVAL_REQD" type="CHAR" isMandatory="true"
length="1"/>
</db-entity>
<db-entity name="K12_DATA_COLLECTION" schema="ESDM">
<db-attribute name="DATA_COLLECTION_ID" type="INTEGER" isPrimaryKey="true"
isMandatory="true" length="22"/>
<db-attribute name="SCHOOL_YEAR" type="TIMESTAMP" isMandatory="true"
length="7"/>
<db-attribute name="SNAPSHOT_DATE" type="TIMESTAMP" isMandatory="true"
length="7"/>
</db-entity>
<db-entity name="DATA_COLLECTION_TYPE" schema="ESDM">
<db-attribute name="COLLECTION_TYPE_DESC" type="VARCHAR" length="255"/>
<db-attribute name="COLLECTION_TYPE_ID" type="INTEGER" isPrimaryKey="true"
isMandatory="true" length="22"/>
<db-attribute name="COLLECTION_TYPE_NAME" type="VARCHAR"
isMandatory="true" length="20"/>
</db-entity>
<obj-entity name="DataCollection"
className="com.escholar.datamgr.model.DataCollection"
dbEntityName="DATA_COLLECTION">
<obj-attribute name="activeInd" type="java.lang.String"
db-attribute-path="ACTIVE_IND"/>
<obj-attribute name="autoCloseDate" type="java.util.Date"
db-attribute-path="AUTO_CLOSE_DATE"/>
<obj-attribute name="autoOpenDate" type="java.util.Date"
db-attribute-path="AUTO_OPEN_DATE"/>
<obj-attribute name="collectionName" type="java.lang.String"
db-attribute-path="COLLECTION_NAME"/>
<obj-attribute name="description" type="java.lang.String"
db-attribute-path="DESCRIPTION"/>
<obj-attribute name="lastModifiedBy" type="java.lang.String"
db-attribute-path="LAST_MODIFIED_BY"/>
<obj-attribute name="lastModifiedTime" type="java.util.Date"
db-attribute-path="LAST_MODIFIED_TIME"/>
<obj-attribute name="schoolYear" type="java.util.Date"
db-attribute-path="SCHOOL_YEAR"/>
<obj-attribute name="snapshotDate" type="java.util.Date"
db-attribute-path="SNAPSHOT_DATE"/>
<obj-attribute name="suptApprovalReqd" type="java.lang.String"
db-attribute-path="SUPT_APPROVAL_REQD"/>
</obj-entity>
<obj-entity name="K12DataCollection" superEntityName="DataCollection"
className="com.escholar.datamgr.model.K12DataCollection"
dbEntityName="DATA_COLLECTION">
<qualifier><![CDATA[collectionTypeId = 3]]></qualifier>
<obj-attribute name="schoolYear" type="java.util.Date"
db-attribute-path="SCHOOL_YEAR"/>
<obj-attribute name="snapshotDate" type="java.util.Date"
db-attribute-path="SNAPSHOT_DATE"/>
</obj-entity>
<obj-entity name="DataCollectionType"
className="com.escholar.datamgr.model.DataCollectionType"
dbEntityName="DATA_COLLECTION_TYPE">
<obj-attribute name="collectionTypeDesc" type="java.lang.String"
db-attribute-path="COLLECTION_TYPE_DESC"/>
<obj-attribute name="collectionTypeId" type="java.lang.Integer"
db-attribute-path="COLLECTION_TYPE_ID"/>
<obj-attribute name="collectionTypeName" type="java.lang.String"
db-attribute-path="COLLECTION_TYPE_NAME"/>
</obj-entity>
<db-relationship name="k12DataCollection" source="DATA_COLLECTION"
target="K12_DATA_COLLECTION" toDependentPK="true" toMany="false">
<db-attribute-pair source="DATA_COLLECTION_ID"
target="DATA_COLLECTION_ID"/>
</db-relationship>
<db-relationship name="dataCollection" source="K12_DATA_COLLECTION"
target="DATA_COLLECTION" toMany="false">
<db-attribute-pair source="DATA_COLLECTION_ID"
target="DATA_COLLECTION_ID"/>
</db-relationship>
<db-relationship name="collectionType" source="DATA_COLLECTION"
target="DATA_COLLECTION_TYPE" toMany="false">
<db-attribute-pair source="COLLECTION_TYPE_ID"
target="COLLECTION_TYPE_ID"/>
</db-relationship>
<db-relationship name="dataCollections" source="DATA_COLLECTION_TYPE"
target="DATA_COLLECTION" toMany="true">
<db-attribute-pair source="COLLECTION_TYPE_ID"
target="COLLECTION_TYPE_ID"/>
</db-relationship>
<obj-relationship name="collectionType" source="DataCollection"
target="DataCollectionType" deleteRule="Nullify"
db-relationship-path="collectionType"/>
<obj-relationship name="k12DataCollection" source="DataCollection"
target="K12DataCollection" deleteRule="Nullify"
db-relationship-path="k12DataCollection"/>
<obj-relationship name="dataCollections" source="DataCollectionType"
target="DataCollection" deleteRule="Deny"
db-relationship-path="dataCollections"/>
I apologize for the confusion.
thanks again,
Julie
<db-relationship name="dataCollections" source="DATA_COLLECTION_TYPE"
target="DATA_COLLECTION" toMany="true">
<db-attribute-pair source="COLLECTION_TYPE_ID"
target="COLLECTION_TYPE_ID"/>
</db-relationship>
--
View this message in context: http://cayenne.195.n3.nabble.com/Vertical-inheritance-tp827636p1352997.html
Sent from the Cayenne - Dev mailing list archive at Nabble.com.
Re: Vertical inheritance
Posted by Julia Filho <jf...@yahoo.com>.
Hi,
Relevant mapping sections are:
<db-entity name="DATA_COLLECTION" schema="ESDM">
<db-attribute name="ACTIVE_IND" type="CHAR" isMandatory="true"
length="1"/>
<db-attribute name="AUTO_CLOSE_DATE" type="TIMESTAMP" length="7"/>
<db-attribute name="AUTO_OPEN_DATE" type="TIMESTAMP" length="7"/>
<db-attribute name="COLLECTION_NAME" type="VARCHAR" isMandatory="true"
length="255"/>
<db-attribute name="COLLECTION_TYPE_ID" type="INTEGER" isMandatory="true"
length="22"/>
<db-attribute name="DATA_COLLECTION_ID" type="INTEGER" isPrimaryKey="true"
isMandatory="true" length="22"/>
<db-attribute name="DESCRIPTION" type="VARCHAR" isMandatory="true"
length="255"/>
<db-attribute name="LAST_MODIFIED_BY" type="VARCHAR" isMandatory="true"
length="20"/>
<db-attribute name="LAST_MODIFIED_TIME" type="TIMESTAMP"
isMandatory="true" length="11"/>
<db-attribute name="SUPT_APPROVAL_REQD" type="CHAR" isMandatory="true"
length="1"/>
</db-entity>
</db-entity>
<db-entity name="K12_DATA_COLLECTION" schema="ESDM">
<db-attribute name="DATA_COLLECTION_ID" type="INTEGER" isPrimaryKey="true"
isMandatory="true" length="22"/>
<db-attribute name="SCHOOL_YEAR" type="TIMESTAMP" isMandatory="true"
length="7"/>
<db-attribute name="SNAPSHOT_DATE" type="TIMESTAMP" isMandatory="true"
length="7"/>
</db-entity>
<db-entity name="DATA_COLLECTION_TYPE" schema="ESDM">
<db-attribute name="COLLECTION_TYPE_DESC" type="VARCHAR" length="255"/>
<db-attribute name="COLLECTION_TYPE_ID" type="INTEGER" isPrimaryKey="true"
isMandatory="true" length="22"/>
<db-attribute name="COLLECTION_TYPE_NAME" type="VARCHAR"
isMandatory="true" length="20"/>
</db-entity>
<obj-entity name="DataCollection"
className="com.escholar.datamgr.model.DataCollection"
dbEntityName="DATA_COLLECTION">
<obj-attribute name="activeInd" type="java.lang.String"
db-attribute-path="ACTIVE_IND"/>
<obj-attribute name="autoCloseDate" type="java.util.Date"
db-attribute-path="AUTO_CLOSE_DATE"/>
<obj-attribute name="autoOpenDate" type="java.util.Date"
db-attribute-path="AUTO_OPEN_DATE"/>
<obj-attribute name="collectionName" type="java.lang.String"
db-attribute-path="COLLECTION_NAME"/>
<obj-attribute name="dataCollectionId" type="java.lang.Integer"
db-attribute-path="DATA_COLLECTION_ID"/>
<obj-attribute name="description" type="java.lang.String"
db-attribute-path="DESCRIPTION"/>
<obj-attribute name="lastModifiedBy" type="java.lang.String"
db-attribute-path="LAST_MODIFIED_BY"/>
<obj-attribute name="lastModifiedTime" type="java.util.Date"
db-attribute-path="LAST_MODIFIED_TIME"/>
<obj-attribute name="suptApprovalReqd" type="java.lang.String"
db-attribute-path="SUPT_APPROVAL_REQD"/>
</obj-entity>
<obj-entity name="K12DataCollection"
className="com.escholar.datamgr.model.K12DataCollection"
dbEntityName="K12_DATA_COLLECTION">
<obj-attribute name="dataCollectionId" type="java.lang.Integer"
db-attribute-path="DATA_COLLECTION_ID"/>
<obj-attribute name="schoolYear" type="java.util.Date"
db-attribute-path="SCHOOL_YEAR"/>
<obj-attribute name="snapshotDate" type="java.util.Date"
db-attribute-path="SNAPSHOT_DATE"/>
</obj-entity>
<obj-entity name="DataCollectionType"
className="com.escholar.datamgr.model.DataCollectionType"
dbEntityName="DATA_COLLECTION_TYPE">
<obj-attribute name="collectionTypeDesc" type="java.lang.String"
db-attribute-path="COLLECTION_TYPE_DESC"/>
<obj-attribute name="collectionTypeId" type="java.lang.Integer"
db-attribute-path="COLLECTION_TYPE_ID"/>
<obj-attribute name="collectionTypeName" type="java.lang.String"
db-attribute-path="COLLECTION_TYPE_NAME"/>
</obj-entity>
<db-relationship name="k12DataCollection" source="DATA_COLLECTION"
target="K12_DATA_COLLECTION" toDependentPK="true" toMany="false">
<db-attribute-pair source="DATA_COLLECTION_ID"
target="DATA_COLLECTION_ID"/>
</db-relationship>
<db-relationship name="dataCollection" source="K12_DATA_COLLECTION"
target="DATA_COLLECTION" toMany="false">
<db-attribute-pair source="DATA_COLLECTION_ID"
target="DATA_COLLECTION_ID"/>
</db-relationship>
<db-relationship name="collectionType" source="DATA_COLLECTION"
target="DATA_COLLECTION_TYPE" toMany="false">
<db-attribute-pair source="COLLECTION_TYPE_ID"
target="COLLECTION_TYPE_ID"/>
</db-relationship>
<db-relationship name="dataCollections" source="DATA_COLLECTION_TYPE"
target="DATA_COLLECTION" toMany="true">
<db-attribute-pair source="COLLECTION_TYPE_ID"
target="COLLECTION_TYPE_ID"/>
</db-relationship>
<obj-relationship name="collectionType" source="DataCollection"
target="DataCollectionType" deleteRule="Nullify"
db-relationship-path="collectionType"/>
<obj-relationship name="k12DataCollection" source="DataCollection"
target="K12DataCollection" deleteRule="Nullify"
db-relationship-path="dataCollection"/>
(I thing that's it)
ANother thing to note is that the superclass, DataCollection is not abstract
- not sure if that matters or not.
thank you very much for your help!
Julie Filho
--
View this message in context: http://cayenne.195.n3.nabble.com/Vertical-inheritance-tp827636p1352592.html
Sent from the Cayenne - Dev mailing list archive at Nabble.com.
Re: Vertical inheritance
Posted by Robert Zeigler <ro...@roxanemy.com>.
Providing the relevant portions of the mapping file would be a good place to start. :)
Robert
On Aug 25, 2010, at 8/2511:10 AM , Julia Filho wrote:
>
> Hi,
>
> Is vertical inheritance not supported in Cayenne 3.0? According to the
> documentation, vertical inheritance is supported, but I am running into
> problems with the generated SELECT query when reading one of the subclasses:
>
> The generated query is:
>
> SELECT t0.DATA_COLLECTION_ID, t0.COLLECTION_TYPE_ID, t0.DATA_COLLECTION_ID,
> t0.SCHOOL_YEAR, t0.SNAPSHOT_DATE FROM ESDM.K12_DATA_COLLECTION t0 JOIN
> ESDM.DATA_COLLECTION t1 ON (t0.DATA_COLLECTION_ID = t1.DATA_COLLECTION_ID)
> JOIN ESDM.DATA_COLLECTION_TYPE t2 ON (t1.COLLECTION_TYPE_ID =
> t2.COLLECTION_TYPE_ID) WHERE t2.COLLECTION_TYPE_ID = ? [bind:
> 1->COLLECTION_TYPE_ID:3]
>
>
> which is a problem because
> 1) column COLLECTION_TYPE_ID is in select list for the subclass
> (K12_DATA_COLLECTION) but that column is in the super class table
> (DATA_COLLECTION), not the subclass
> 2) DATA_COLLECTION_ID is in the K12_DATA_COLLECTION select list twice.
>
> Do you have any suggestions, or is this functionality not yet supported?
>
> thank you for any assistance you can give
> Julie
>
>
> --
> View this message in context: http://cayenne.195.n3.nabble.com/Vertical-inheritance-tp827636p1334340.html
> Sent from the Cayenne - Dev mailing list archive at Nabble.com.
Re: Vertical inheritance
Posted by Julia Filho <jf...@yahoo.com>.
Hi,
Is vertical inheritance not supported in Cayenne 3.0? According to the
documentation, vertical inheritance is supported, but I am running into
problems with the generated SELECT query when reading one of the subclasses:
The generated query is:
SELECT t0.DATA_COLLECTION_ID, t0.COLLECTION_TYPE_ID, t0.DATA_COLLECTION_ID,
t0.SCHOOL_YEAR, t0.SNAPSHOT_DATE FROM ESDM.K12_DATA_COLLECTION t0 JOIN
ESDM.DATA_COLLECTION t1 ON (t0.DATA_COLLECTION_ID = t1.DATA_COLLECTION_ID)
JOIN ESDM.DATA_COLLECTION_TYPE t2 ON (t1.COLLECTION_TYPE_ID =
t2.COLLECTION_TYPE_ID) WHERE t2.COLLECTION_TYPE_ID = ? [bind:
1->COLLECTION_TYPE_ID:3]
which is a problem because
1) column COLLECTION_TYPE_ID is in select list for the subclass
(K12_DATA_COLLECTION) but that column is in the super class table
(DATA_COLLECTION), not the subclass
2) DATA_COLLECTION_ID is in the K12_DATA_COLLECTION select list twice.
Do you have any suggestions, or is this functionality not yet supported?
thank you for any assistance you can give
Julie
--
View this message in context: http://cayenne.195.n3.nabble.com/Vertical-inheritance-tp827636p1334340.html
Sent from the Cayenne - Dev mailing list archive at Nabble.com.
Re: Vertical inheritance
Posted by Andrus Adamchik <an...@objectstyle.org>.
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.
>