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
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, 201
>
>
>target="K12_DATA_COLLECTION" toDependentPK="true" toMany="false">
>target="DATA_COLLECTION_ID"/>
>
>
> target="DATA_COLLECTION" toMany="false">
>
for the confusion.
thanks again,
Julie
--
View this message in context:
http://cayenne.195.n3.nabble.com/Vertical-inheritance-tp827636p1352997.html
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 archi
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 supp
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
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 i
ndrus 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
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
>
or 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 essentiall
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
ot
> 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 jus
e 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
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 h
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. Whi
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 bas
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 fa
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 t
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 - t
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
"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
t 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 th
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
motivatio
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 f
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 res
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 (
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 doin
Makes sense.
Andrus
On Nov 10, 2008, at 10:43 AM, Aristedes Maniatis wrote:
On 10/11/2008, at 7:31 PM, Andrus Adamchik wrote:
That's too optimistic (i.e. not gonna happen) .I think we should
keep 3.0 (without specific milestone) as a Fix Version for most
things, and change it to a next m
On 10/11/2008, at 7:31 PM, Andrus Adamchik wrote:
That's too optimistic (i.e. not gonna happen) .I think we should
keep 3.0 (without specific milestone) as a Fix Version for most
things, and change it to a next milestone once the issue is closed.
I wanted to do some triaging though to get
On Nov 10, 2008, at 10:25 AM, Ari Maniatis (JIRA) wrote:
Ari Maniatis updated CAY-1090:
--
Fix Version/s: (was: Short term future)
3.0M5
Assignee: Andrus Adamchik (was: Ari Maniatis)
That's too optimistic (i.e. not gonna happen)
Vertical inheritance
Key: CAY-1090
URL: https://issues.apache.org/cayenne/browse/CAY-1090
Project: Cayenne
Issue Type: New Feature
Components: Cayenne Core Library
Affects Versions: 3.0
mentioned that already??).
Well the original suggestion I made was for superRelationship="nameOfRelationship" ...> to allow for
specifically specifying vertical inheritance (which would have the
effect of not listing this relationship along with those re
suggestion I made was for superRelationship="nameOfRelationship" ...> to allow for
specifically specifying vertical inheritance (which would have the
effect of not listing this relationship along with those returned
from objEntity.getRelationships() but via
objEntity.getSupe
nship" ...> to allow for specifically
specifying vertical inheritance (which would have the effect of not
listing this relationship along with those returned from
objEntity.getRelationships() but via objEntity.getSuperRelationship().
Are you suggesting that you'd prefer
This was a long thread, and I may have missed some points already
made. Let me try to summarize this discussion and add my comments to
it. There are two aspects of the "vertical inheritance relationship":
1. Specifying the join semantics for non-trivial PK-to-PK mapping
(such a
es are not exposed in the
ObjEntity anyway, so I agree with what I think you are saying. But
the question here is about compound primary keys. If we want to be
able to support them as the basis for the join in vertical
inheritance, then we need an objRelationship explicitly defined.
Wel
37 matches
Mail list logo
