2018-02-16 20:46 GMT+01:00 Jason Bennett <[email protected]>: > > > On Friday, February 16, 2018 at 1:44:10 AM UTC-8, Lukas Eder wrote: >> >> What specificity were you missing from *Ambiguous match found for id. >> Both "child"."id" and "parent"."id" match" *? >> >> > > Once I got that far, I agree the message was sufficient. Maybe this is my > lack of understanding of jOOQ and aliasing, but I had a lot of struggles > realizing that I needed to use the aliases instead of the table name in > basically every place I might refer to the table. I guess that seems > obvious now that I've written it. Not sure if jOOQ can throw an error if it > sees aliases used in some places of the query, but not others. >
I'm still not sure what this means... If you write a query (in SQL) like: SELECT actor.*, co_actor.* FROM actor JOIN film_actor fa1 ON actor.actor_id = fa1.actor_id JOIN film_actor fa2 ON fa1.film_id = fa2.film_id JOIN actor AS co_actor ON fa2.actor_id = co_actor.actor_id Only the latter of the actor tables is renamed. It's perfectly fine not to rename the first. It seems obvious in SQL that the column reference actor.actor_id now references the first table, whereas co_actor.actor_id references the second table, and plain "actor_id" would be ambiguous, no? So, maybe, I'm still misunderstanding the problem here, but I'm not sure how jOOQ can provide better error messages. I'd probably need an actual query where the jOOQ behaviour is confusing. > 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. >>> >> >> That's never an option. >> >> > > Sorry, what is not an option? > Introducing N+1 problems because the client code looks cleaner :-) Either, the client code needs fixing, or jOOQ. But N+1 is a very high price to pay for a bit of convenience. > > >> >> What does it mean that the "main issue is not having a key"? A key to >> what? Why is a "pair" better than a Map.Entry? I'm assuming you're already >> lost in your exploration of possibilities, describing your attempts to find >> the way out of this "forest". It would be much better to reset your >> expectations and start again from the ideal solution, display that, and >> then ask - how can I best get there. Quite possibly, there is a jOOQ >> feature I could show you, or a third party tool, or I could add a feature >> request. >> >> > Well, I'm certainly not suggesting that jOOQ should be Hibernate, or even > myBatis - I understand that's not what it wants to be. I'm mainly > suggesting that there be a way to fetch a query that assumes a single > parent row (like fetchOne or fetchSingle), with an attached list of > children. > Pair is better than Map.Entry because there's no easy way to get at a > single Map.Entry, without calling the iterator and taking the first one. > That does work, it just looks messy. > > So, given a query that should return only a single "main" object, with one > or more children, is there a good way for jOOQ to represent that, without > returning a structure that assumes multiple "parent" objects the way that > Map does. I hope that is a clearer expression of what I'm looking for. > Oh, I see now. Thanks for clarifying. Now that you put it this way, it does make a lot of sense indeed. So, in addition to calling fetchGroups() which returns a Map<K, List<V>> type, you would like to be able to call a fetchGroup() method, which fetches a single group only (throwing an exception if there would be more than one group) of the type Map.Entry<K, List<V>>. Is that correct? -- 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.
