Hi Daniel, Issue #2836 could be solved for jOOQ 3.3: https://github.com/jOOQ/jOOQ/issues/2836
I won't merge this fix to jOOQ 3.2, as this fix introduces a subtle change of behaviour to the DefaultRecordMapper, which might be unexpected Cheers Lukas 2013-12-07 Lukas Eder <[email protected]>: > This issue is in fact the same as the one being discussed here: > https://groups.google.com/d/msg/jooq-user/OTXq3ePpdtw/AMKaFH9s8bIJ > > The problem arises when people want to fetch an active record (FooRecord), > which they can store after fetching. At the same time, they want to use a > JOIN to express a semi-join predicate, which could also be expressed with > IN: > > // This query... > > select().from(FOO.join(BAR).on(...)).where(...conditions...).fetchOneInto(FooRecord.class); > > // ... has the same intent as this one: > selectFrom(FOO).where(FOO.ID.in(select(BAR.ID > ).from(BAR)).and(...conditions...).fetch(); > > > For your particular solution, I guess that the DefaultRecordMapper should > be fixed in a way that whenever the passed <E> type (FooRecord.class) is a > type implementing TableRecord, then the mapping should take that Record's > TableFields into consideration. > > The algorithm might be quite difficult to implement correctly without > introducing regressions. > > I'll think about these things a bit longer. > Cheers > Lukas > > > 2013/11/10 Lukas Eder <[email protected]> > >> Hi Daniel, >> >> I'm sorry for the delay. I've been presenting jOOQ at the Topconf in >> Tallinn, so a couple of E-Mails have been piling up. >> >> >> 2013/11/5 Daniel Danilatos <[email protected]> >> >>> >>> >>> >>> On Tue, Sep 3, 2013 at 1:39 AM, Lukas Eder <[email protected]> wrote: >>>> >>>> Example use case 2: Disambiguate fields. If I go dsl.select()... with >>>>> some joins, and the table field names clash, jooq / sql will not complain >>>>> because when generating the SQL jooq disambiguates the field names with >>>>> tables. However in the returned records, it seems that table names are >>>>> ignored and whatever fields came last clobber earlier fields (usually one >>>>> would prefer the other way round, but that's not 100% of the time either). >>>>> >>>> >>>> That shouldn't be the case. If you have an exact match of table name / >>>> field name, you should get the right value, even if field names clash. Can >>>> you provide a test case to reproduce the issue? >>>> >>> >>> I've run into this again. To clarify, I'm not aliasing fields; I'm just >>> doing what is effectively: >>> >>> select().from(FOO.join(BAR).on(FOO.ID.eq(BAR.ID >>> ))).where(...conds...).fetchOneInto(FooRecord.class) >>> >>> And jooq is generating >>> >>> select foo.id, foo.xxx, bar.id, bar.yyy from foo join bar on (foo.id= >>> bar.id) where ... >>> >>> In my use case, the main records I'm after here are "foo" records, and >>> the joins are for various filterings and so on. But because "bar" comes >>> after, and happens to also have a field named "id", I guess jooq is using >>> bar's value of "id" even though in the generated SQL it's qualifying all >>> the fields. So I end up with an instance of FooRecord which has bar's id in >>> it, that seems wrong no matter which way you look at it. Somewhere in >>> there, jooq's lost the fact that the "id" came from "bar", rather than >>> disambiguating when placing values into the FooRecord. I think it would >>> equally make sense that if I went .fetchOneInto(BarRecord.class) that i'd >>> get bar's id in there. >>> >>> The workaround is to explicitly enumerate the fields, e.g. >>> >>> select(FOO.ID, FOO.XXX).from(.... rest is the same... >>> >>> (or FOO.fields()) >>> >>> This is OK because I don't need any of Bar's fields. But I feel uneasy >>> knowing that if I accidentally neglect to be explicit about the fields, >>> everything will "seem to work" except I'll have wrong data in my retrieved >>> records. >>> >> >> Yes, this does indeed seem problematic. So far, I might not have been >> paying enough attention to the fact that you're using >> .fetchOneInto(BarRecord.class). I will have to play around with a couple of >> scenarios and I've registered #2836 for this >> https://github.com/jOOQ/jOOQ/issues/2836 >> >> I'll have to check if there are sufficient formal connections between the >> resulting FOO.ID column and the FooRecord.setId() setter, to make >> assignment unambiguous. >> >> Cheers >> Lukas >> > > -- 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/groups/opt_out.
