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.
