Hi Lukas, Thank you very much for your quick reply! I'm glad to hear that it's not a bug, but just a misunderstanding on my side. That's much quicker to fix ;-) I've just updated my code, and indeed: everything works fine!
Good idea to update the example documentation. Thanks again for your quick help and have a nice day, Paul On Monday, July 3, 2017 at 10:41:54 AM UTC+2, Lukas Eder wrote: > > Hi Paul, > > Thank you very much for your report. This looks very interesting, but it's > not a bug. The record you're creating in your MockDataProvider has three > columns, which happen to be named A (index 0), B (index 1), and C (index > 2). This is because you're using: > > Result<ListRecord> result = create.newResult(LIST); > result.add(create.newRecord(LIST)); > > > Rather than: > > Result<Record2<Integer, Integer>> result = create.newResult(LIST.A, > LIST.C); > result.add(create.newRecord(LIST.A, LIST.C)); > > > Indeed, it looks like the two versions should work exactly the same way > because you always used the correct field names, but unfortunately, that's > not how SQL works in many cases. For instance, top-level selects are > allowed to contain two times the exact same field name, even when they're > qualified. E.g. many databases allow for this: > > SELECT * FROM LIST, LIST > > > If you do this, what's LIST.A and LIST.C? The first copy, or the second > copy? > > This is why jOOQ (just like JDBC) works with column indexes in most cases, > which are never ambiguous. > > We'll adapt the manual example, as the current example is indeed > misleading. Thank you very much for pointing this out to us! > > I hope this helps, > Lukas > > 2017-07-03 9:27 GMT+02:00 <[email protected] <javascript:>>: > >> Hi guys, >> >> I think I may have found a bug in the jOOQ mocking framework. >> >> Based on this page: >> https://www.jooq.org/doc/3.9/manual/tools/jdbc-mocking/ >> I have made a MockDataProvider of my own. Quite easy indeed, really >> awesome. However, I ran into what seems to be a bug in jOOQ. Let me try to >> explain: >> >> Suppose I have a database with the following simple tiny table "List": >> >> A | B | C >> ---+---+--- >> 1 | 2 | 3 >> >> So, 3 columns A, B and C of type INT, and a single row. >> >> Then, in my unittest, I want to mock the result of the following query >> (that I represent using jOOQ ofcourse): SELECT A,C FROM List >> Following the MockDataProvider example provided on the previously >> mentioned page, a piece of my implementation of the MockDataProvider >> execute() method would look like: >> >> 1 if (sql.toUpperCase().startsWith("SELECT")) { >> 2 Result<ListRecord> result = create.newResult(LIST); >> 3 result.add(create.newRecord(LIST)); >> 4 result.get(0).setValue(LIST.A, 1); >> 5 result.get(0).setValue(LIST.C, 3); >> 6 mock[0] = new MockResult(1, result); >> 7 } >> >> Now, the expected result would be a row containing: 1,3 >> however, the actual result is: 1,null >> >> 09:06:17.677 [main] DEBUG org.jooq.tools.LoggerListener - Fetched result >> : +----+------+ >> 09:06:17.677 [main] DEBUG org.jooq.tools.LoggerListener - >> : | A| C| >> 09:06:17.677 [main] DEBUG org.jooq.tools.LoggerListener - >> : +----+------+ >> 09:06:17.677 [main] DEBUG org.jooq.tools.LoggerListener - >> : | 1|{null}| >> 09:06:17.677 [main] DEBUG org.jooq.tools.LoggerListener - >> : +----+------+ >> >> To get it right, I would have to change line 5 to: >> >> 5 result.get(0).setValue(*LIST.B*, 3); >> >> Now the result is what I would have expected in the first place: >> >> 09:09:18.875 [main] DEBUG org.jooq.tools.LoggerListener - Fetched result >> : +----+----+ >> 09:09:18.876 [main] DEBUG org.jooq.tools.LoggerListener - >> : | A| C| >> 09:09:18.876 [main] DEBUG org.jooq.tools.LoggerListener - >> : +----+----+ >> 09:09:18.876 [main] DEBUG org.jooq.tools.LoggerListener - >> : | 1| 3| >> 09:09:18.876 [main] DEBUG org.jooq.tools.LoggerListener - >> : +----+----+ >> >> So it seems, in order to fill the column addressed by the SECOND argument >> in my query, my setValue() call needs to address the field representing the >> SECOND column in the actual database schema. This is obviously not correct. >> But in this example it's not so bad; however weird, the workaround is >> rather simple. However, when the second column of my database schema would >> have been a VARCHAR type column, my workaround would not work due to type >> incompatibilities. So no workaround for me unfortunately :-( >> >> Can someone please have a look at this problem? >> >> I'm using jOOQ Trial version 3.9.3. I've attached a working code example >> including db schema. >> >> Kind regards, >> Paul Hamer >> >> -- >> 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] <javascript:>. >> 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.
