Darn… Took a better look at the model, turns out the “product_link.product_id" field was a string, while “product.id” was an integer. Changing both fields to integers resolved the issue. As I said this morning; not enough coffee in me :).
PErhaps adding validation for matching types in relationships might be helpful, even if it’d just emit a warning when the runtime is initialized (or in the Modeler)? These days, EOF refuses to start up an EOF stack if any modeled relationships have joins on different value types (unless a property is set to explicitly allow it). I’d love to write and contribute a check like that if you believe it would be useful. Cheers, - hugi > On 13. maí 2015, at 09:34, Andrus Adamchik <and...@objectstyle.org> wrote: > > Yeah a bug report would be great. But we'll need more information to > reproduce the problem. A disjoint prefetch on to-one is the most common case > and it works of course, so there has to be something special about your DB or > your mapping. A full DataMap (or at least the part with these 2 entities) > should help. If you can't expose it publicly, you can still open a Jira, and > email me the mapping privately. > > Thanks, > Andrus > >> On May 13, 2015, at 12:29 PM, Hugi Thordarson <h...@karlmenn.is> wrote: >> >> Thanks Andrus. Setting the semantics to >> PrefetchTreeNode.JOINT_PREFETCH_SEMANTICS made the relationship resolve >> properly (and modified the SQL to use a join rather than a separate fetch >> for fetching the products). Looks like a bug, shouldn’t I report this? >> >> And I’m generating properties in my template—I’m just using slightly >> modified templates for easier conversion of my old EOF code. >> >> Cheers, >> - hugi >> >> // Hugi Thordarson >> // http://www.loftfar.is/ <http://www.loftfar.is/> >> // s. 895-6688 >> >> >> >>> On 13. maí 2015, at 09:00, Andrus Adamchik <and...@objectstyle.org> wrote: >>> >>> Actually it is performed. It is a "disjoint prefetch", so a second query is >>> generated. I still don't see any clues as to why the prefetch is not >>> working, so here is a purely random suggestion: you can try other prefetch >>> strategies and see if that makes any difference. E.g.: >>> >>> query.addPrefetch( ProductLink.PRODUCT_KEY >>> ).setSemantics(PrefetchTreeNode.JOINT_PREFETCH_SEMANTICS); >>> >>> or >>> >>> query.addPrefetch( ProductLink.PRODUCT_KEY >>> ).setSemantics(PrefetchTreeNode.DISJOINT_BY_ID_PREFETCH_SEMANTICS); >>> >>> (BTW, looks like you are not using 4.0 cgen templates that would generate >>> Property objects for each property?) >>> >>> Andrus >>> >>>> On May 13, 2015, at 11:48 AM, Hugi Thordarson <h...@karlmenn.is> wrote: >>>> >>>> Hi Andrus. >>>> Sure, here it is. Looks like a fetch is never performed for the “products” >>>> relationship… >>>> >>>> https://gist.github.com/hugith/6d0ccde4aa8877e26454 >>>> >>>> Thanks! >>>> - hugi >>>> >>>> // Hugi Thordarson >>>> // http://www.loftfar.is/ <http://www.loftfar.is/> >>>> // s. 895-6688 >>>> >>>> >>>> >>>>> On 13. maí 2015, at 08:36, Andrus Adamchik <and...@objectstyle.org> wrote: >>>>> >>>>> Can you post the generated SQL by any chance? Also is there anything >>>>> special about the relationship, or is it a simple to-one ? >>>>> >>>>> Andrus >>>>> >>>>>> On May 12, 2015, at 6:02 PM, Hugi Thordarson <h...@karlmenn.is> wrote: >>>>>> >>>>>> Hi all. >>>>>> >>>>>> I have a weird case (using Cayenne 4.0-M2) where if I add a prefetch to >>>>>> a relationship, the relationship is nullified (will contain nothing). >>>>>> Consider the following code: >>>>>> >>>>>> SelectQuery<ProductLink> q = SelectQuery.query( ProductLink.class ); >>>>>> q.addPrefetch( ProductLink.PRODUCT_KEY ); // <---- This line is the >>>>>> culprit >>>>>> >>>>>> List<ProductLink> links = oc().select( q ); >>>>>> >>>>>> for( ProductLink link : links ) { >>>>>> System.out.println( link.product() ); >>>>>> } >>>>>> >>>>>> Without the prefetch, the “product” relationship is properly populated >>>>>> for each “ProductLink” object, but if I include the prefetch, the >>>>>> relationship is always null. >>>>>> >>>>>> Any ideas? >>>>>> >>>>>> Cheers, >>>>>> - hugi >>>>> >>>> >>> >> >
