I agree it makes sense, although it might be nice if jOOQ gave a specific error message when you alias some parts of the query, and not others.
fetchMap is ok, but the main issue is I have no key. The only way to get the keys is to iterate through the entrySet, which isn't the cleanest code. This is a lot easier in something like Kotlin, where you can give me a pair of the parent and a list of children. I suspect in Java, unless you want to have a jOOQ pair type, we're stuck with the map. I did experiment with fetchParent and fetchChildren, although my main concern there is the second query. Still, that makes my code a lot cleaner, at the expense of slightly more DB time. I do with that the documentation was a little clearer about my options. All of this stuff is in there somewhere, but it's a little scattered. On Fri, Feb 16, 2018 at 12:38 AM, Lukas Eder <[email protected]> wrote: > That's what I thought. Of course there's an ambiguity if you're using the > actual table name, rather than the aliased tables - that makes sense, no? :) > > I think that by "fetchOne with fetchGroups" you might mean "fetchMap"? > Does that work better for you? > > What would be a better API for your particular use-case? > > 2018-02-15 23:47 GMT+01:00 Jason Bennett <[email protected]>: > >> Ok, using "child" and "parent" as part of fetchGroups allows this to >> work. It's still a little annoying to deal with the map and list (since >> there's no fetchOne with fetchGroups), but otherwise this behaves as I'd >> expect. Thanks to everyone for their help. >> >> >> On Thursday, February 15, 2018 at 1:09:44 PM UTC-8, Jason Bennett wrote: >>> >>> Here's another attempt at using fetchGroups, jOOQ says >>> "JooqLogger.java:370 - Ambiguous match found for id. Both "child"."id" and >>> "parent"."id" match": >>> >>> Map<ProductionEntityRecord, List<ProductionEntityRecord>> m = >>> this.create.select() >>> .from(child) >>> .leftJoin(parent) >>> .on(child.PARENT_PRODUCTION_ENTITY_ID.eq(parent.ID)) >>> .where(child.EXTERNAL_ID.eq(externalId)) >>> .fetchGroups(c -> c.into(PRODUCTION_ENTITY), >>> p -> p.into(PRODUCTION_ENTITY)); >>> >>> >>> This also has the disadvantage of not letting me "fetchOne" and having >>> to deal with the map key iterator in an awkward way. >>> >>> On Thursday, February 15, 2018 at 10:03:40 AM UTC-8, Jason Bennett wrote: >>>> >>>> Here's where I've ended up: >>>> >>>> com.ep.core.project.jooq.tables.ProductionEntity parent = >>>> PRODUCTION_ENTITY.as("parent"); >>>> com.ep.core.project.jooq.tables.ProductionEntity child = >>>> PRODUCTION_ENTITY.as("child"); >>>> >>>> Record7<Long, UUID, String, String, OffsetDateTime, OffsetDateTime, UUID> >>>> r = >>>> this.create.select(child.ID, >>>> child.EXTERNAL_ID, >>>> child.NAME, >>>> child.SLUG, >>>> child.CREATED, >>>> child.UPDATED, >>>> parent.EXTERNAL_ID) >>>> .from(child) >>>> .leftJoin(parent) >>>> .on(child.PARENT_PRODUCTION_ENTITY_ID.eq(parent.ID)) >>>> .where(child.NAME.eq(name)) >>>> .fetchOne(); >>>> >>>> >>>> What I would love is to somehow get a parent object and a separate UUID >>>> out of that query, without having to resort to that ugly Result object. >>>> >>>> >>>> >>>> >>>> On Thursday, February 15, 2018 at 12:20:49 AM UTC-8, Lukas Eder wrote: >>>>> >>>>> This should work if either: >>>>> >>>>> 1. The columns are fully qualified >>>>> 2. The columns are renamed >>>>> >>>>> How di you run your query and how did you call fetchGroups()? >>>>> >>>>> 2018-02-14 21:14 GMT+01:00 <[email protected]>: >>>>> >>>>>> Normally when I do a join query, I just use fetchGroups() and fetch >>>>>> the records into their respective types, then iterate across entryKey() - >>>>>> no problem. >>>>>> >>>>>> When I do this with a recursive join, however, jOOQ appears to get >>>>>> confused, and cannot distinguish between the child record and the parent >>>>>> record (I assume since the column names are the same). What's the best >>>>>> way >>>>>> to fetch this? >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "jOOQ User Group" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> -- >> You received this message because you are subscribed to the Google Groups >> "jOOQ User Group" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to a topic in the > Google Groups "jOOQ User Group" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/jooq-user/iGsEhmqjf7w/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Jason Bennett, [email protected] E pur si muove! -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
