Heh… Runtime relationships were intended to solve a single problem of updating FK in a one-way to-many relationship. But it created so much trouble for everyone instead. Things like vertical inheritance for instance… oh well.
Andrus On Jun 18, 2013, at 10:22 AM, John Huss <[email protected]> wrote: > For what it's worth, I've had this commented out for quite some time now > and have been running it in production. It was necessary because my entity > classes are subclasses of PersistentObject rather than CayenneDataObject > and they don't have any place to store the generated "runtimeRelationshipX" > values. > > John > > > On Tue, Jun 18, 2013 at 6:21 AM, Andrus Adamchik > <[email protected]>wrote: > >> FYI … another case of runtime rels messing things up. Time to get rid of >> them, replacing the functionality with some other algorithm. >> >> Andrus >> >> >> Begin forwarded message: >> >>> --- >> a/framework/cayenne-jdk1.5-unpublished/src/main/java/org/apache/cayenne/configuration/server/DataDomainProvider.java >>> +++ >> b/framework/cayenne-jdk1.5-unpublished/src/main/java/org/apache/cayenne/configuration/server/DataDomainProvider.java >>> @@ -193,7 +193,7 @@ public class DataDomainProvider implements >> Provider<DataDomain> { >>> } >>> >>> dataDomain.getEntityResolver().applyDBLayerDefaults(); >>> - dataDomain.getEntityResolver().applyObjectLayerDefaults(); >>> + //dataDomain.getEntityResolver().applyObjectLayerDefaults(); >>> >>> for (DataNodeDescriptor nodeDescriptor : >> descriptor.getNodeDescriptors()) { >>> DataNode dataNode = new DataNode(nodeDescriptor.getName()); >>> >>> >>> Feel free to create a custom DataDomainProvider with this change and >> bind it via DI... On the Cayenne end we'll probably need to get rid of >> "runtime" obj relationships. But that's something that will require more >> research. >> >>
