Re: Vertical inheritance
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
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. Should be 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
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: > > >length="1"/> >length="7"/> >length="7"/> >isMandatory="true" > length="255"/> >isMandatory="true" length="22"/> >isPrimaryKey="true" isMandatory="true" length="22"/> >isMandatory="true" > length="255"/> >isMandatory="true" > length="20"/> >isMandatory="true" length="11"/> > > >isMandatory="true" > length="1"/> > > > > >isPrimaryKey="true" isMandatory="true" length="22"/> >isMandatory="true" > length="7"/> >isMandatory="true" > length="7"/> > > > >length="255"/> >isPrimaryKey="true" isMandatory="true" length="22"/> >isMandatory="true" length="20"/> > > > > >className="com.escholar.datamgr.model.DataCollection" > dbEntityName="DATA_COLLECTION"> >db-attribute-path="ACTIVE_IND"/> >db-attribute-path="AUTO_CLOSE_DATE"/> >db-attribute-path="AUTO_OPEN_DATE"/> >db-attribute-path="COLLECTION_NAME"/> >db-attribute-path="DESCRIPTION"/> >db-attribute-path="LAST_MODIFIED_BY"/> >db-attribute-path="LAST_MODIFIED_TIME"/> >db-attribute-path="SCHOOL_YEAR"/> >db-attribute-path="SNAPSHOT_DATE"/> >db-attribute-path="SUPT_APPROVAL_REQD"/> > >className="com.escholar.datamgr.model.K12DataCollection" > dbEntityName="DATA_COLLECTION"> > >db-attribute-path="SCHOOL_YEAR"/> >db-attribute-path="SNAPSHOT_DATE"/> > > >className="com.escholar.datamgr.model.DataCollectionType" > dbEntityName="DATA_COLLECTION_TYPE"> >db-attribute-path="COLLECTION_TYPE_DESC"/> >db-attribute-path="COLLECTION_TYPE_ID"/> >db-attribute-path="COLLECTION_TYPE_NAME"/> > > > >target="K12_DATA_COLLECTION" toDependentPK="true" toMany="false"> >target="DATA_COLLECTION_ID"/> > > >target="DATA_COLLECTION" toMany="false"> >target="DATA_COLLECTION_ID"/> > > >target="DATA_COLLECTION_TYPE" toMany="false"> >target="COLLECTION_TYPE_ID"/> > > >target="DATA_COLLECTION" toMany="true"> >target="COLLECTION_TYPE_ID"/> > > > >target="DataCollectionType" deleteRule="Nullify" > db-relationship-path="collectionType"/> > >target="K12DataCollection" deleteRule="Nullify" > db-relationship-path="k12DataCollection"/> > >target="DataCollection" deleteRule="Deny" > db-relationship-path="dataCollections"/> > > > I apologize for the confusion. > > thanks again, > Julie > > > >target="DATA_COLLECTION" toMany="true"> >target="COLLECTION_TYPE_ID"/> > > -- 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
Hi, Please disregard my previous post - those mappings were from the wrong mapping file. These are the mappings I am using: I apologize for the confusion. thanks again, Julie -- 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
Hi, Relevant mapping sections are: (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
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
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
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
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
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
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 >> 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
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 > 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
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 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 > 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
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 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
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
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 > 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
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 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
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
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 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
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
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
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 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
> 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
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 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
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 > 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 wo
Re: Vertical inheritance
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 > 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
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 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
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 joins
Hi Andrus, On 03/06/2007, at 7:12 PM, Andrus Adamchik wrote: On Jun 1, 2007, at 3:24 PM, Lachlan Deck wrote: On 01/06/2007, at 7:32 PM, Andrus Adamchik wrote: With this in mind we do not need an inheritance ObjRelationship, but we may use a DbRelationship to store join semantics (anybody 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 returned from objEntity.getRelationships() but via objEntity.getSuperRelationship(). This is what I was trying to avoid - introducing relationships with special behavior. Okay. It'd be perhaps less obvious what type of inheritance was in play in the modeller but then again perhaps a simple dynamic label could display something to the same effect along with the below validation. Are you suggesting that you'd prefer superRelationship="nameOfRelationship" ...> No, as DbEntities (tables) do not have inheritance among themselves. It would be more of superDbRelationship="nameOfDBRelationship" ...>, but I do believe that this can be made implicit, as arguably there can be only one DbRelationship between the primary keys of two tables. E.g: SuperOE -> DB1 SubOE1 -> DB2 SubOE2 -> DB3 In this case Cayenne can easily figure out the name of DB2->DB1 and DB3->DB1 relationships based on relationship semantics. Okay great. I suppose there'd need to be validation to that effect to ensure that such relations exist when choosing a different DbEntity from the parent entity. Another nice side effect of it is that such relationship is not a part of the object model (ObjRelationship would've been an object property). So there is nothing artificial about such mapping, and no new concepts are needed in Cayenne to map it. Can you clarify this a bit more. See above - I don't want to redefine what ObjRelationship is. The difference between Cayenne and EOF is that Cayenne splits DB and Java mapping in two separate layers of metadata. EOF allows to mark a relationship as "not included in the object model", while Cayenne allows to map the DB relationship without mapping corresponding ObjRelationship, essentially achieving the same thing in a different way. Thanks. Just a slight mind-shift ;-) with regards, -- Lachlan Deck
Re: vertical inheritance joins
Hi Lachlan, On Jun 1, 2007, at 3:24 PM, Lachlan Deck wrote: On 01/06/2007, at 7:32 PM, Andrus Adamchik wrote: With this in mind we do not need an inheritance ObjRelationship, but we may use a DbRelationship to store join semantics (anybody 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 returned from objEntity.getRelationships() but via objEntity.getSuperRelationship(). This is what I was trying to avoid - introducing relationships with special behavior. Are you suggesting that you'd prefer superRelationship="nameOfRelationship" ...> No, as DbEntities (tables) do not have inheritance among themselves. It would be more of superDbRelationship="nameOfDBRelationship" ...>, but I do believe that this can be made implicit, as arguably there can be only one DbRelationship between the primary keys of two tables. E.g: SuperOE -> DB1 SubOE1 -> DB2 SubOE2 -> DB3 In this case Cayenne can easily figure out the name of DB2->DB1 and DB3->DB1 relationships based on relationship semantics. Another nice side effect of it is that such relationship is not a part of the object model (ObjRelationship would've been an object property). So there is nothing artificial about such mapping, and no new concepts are needed in Cayenne to map it. Can you clarify this a bit more. See above - I don't want to redefine what ObjRelationship is. The difference between Cayenne and EOF is that Cayenne splits DB and Java mapping in two separate layers of metadata. EOF allows to mark a relationship as "not included in the object model", while Cayenne allows to map the DB relationship without mapping corresponding ObjRelationship, essentially achieving the same thing in a different way. Andrus
Re: vertical inheritance joins
On 01/06/2007, at 7:32 PM, Andrus Adamchik wrote: With this in mind we do not need an inheritance ObjRelationship, but we may use a DbRelationship to store join semantics (anybody 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 returned from objEntity.getRelationships() but via objEntity.getSuperRelationship(). Are you suggesting that you'd prefer superRelationship="nameOfRelationship" ...> or just figuring out the relationship by finding the one that happens to map to the parent as a toOne? The nice thing I thought about having a superRelationship definition in the modeler is that you can then make your inheritance choice in one place and it's clear of the choice. i.e., the above would just require an additional popup next to the popup for which DbEntity an ObjEntity maps to to choose a relationship. Otherwise perhaps it wouldn't be as clear whether such a relationship exists. The other option I considered initially was having superRelationship as a boolean flag with validation to ensure there was an accompanying relationship called 'super' but thought this unnecessarily restrictive in the end. Another nice side effect of it is that such relationship is not a part of the object model (ObjRelationship would've been an object property). So there is nothing artificial about such mapping, and no new concepts are needed in Cayenne to map it. Can you clarify this a bit more. Thanks. with regards, -- Lachlan Deck
Re: vertical inheritance joins
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 as compound keys). 2. Specifying delete rules. I am with Ari on (1) - it is in the Cayenne philosophy to map things explicitly, so that various weird legacy schemas can still be mapped. I am with Craig on (2) - if a user expects to delete a record from a subclass table without deleting a record in a superclass table, this situation should not be mapped as inheritance, as it breaks the ORM model at a fundamental level (an object is deleted, but some of its properties still remain persistent - BAD). With this in mind we do not need an inheritance ObjRelationship, but we may use a DbRelationship to store join semantics (anybody mentioned that already??). Another nice side effect of it is that such relationship is not a part of the object model (ObjRelationship would've been an object property). So there is nothing artificial about such mapping, and no new concepts are needed in Cayenne to map it. Andrus
