2015-07-17 0:30 GMT+02:00 Alok Menghrajani <[email protected]>: > Hey Lukas, > > Thanks for getting back on this. The way I was imagining it would be > something that would warn the developer in development mode. >
Aha, I see. Something like a set of programming style rules, such as are available in FindBugs and PMD and other code quality tools - except that with jOOQ, this can be done only once a query is executed at runtime. But it's still rather difficult to assess whether the selected columns will really be needed or not. I mean, I suspect that all the involved objects need to be tagged and tracked throughout your app until they're garbage collected... It's a very interesting topic, though. Not only given your specific use-case of calling fetchInto(Table), but in general. I mean, people keep adding columns to complex SELECT statements as they need more data from the database, but hardly anyone ever dares removing a column, because the consuming side may well be in the frontend... I think that real value would be generated from being able to actually measure end-to-end performance, collecting statistics from the database and tracking problematic queries back through jOOQ to client code. 1-2 excess columns aren't a problem, but they can be if they enforce suboptimal execution plans... > In such a setup, something "too clever" which might have false positives > isn't a big deal (as long as there's a way to disable for specific queries). > Personally, I don't really agree. I've given PMD several chances but the huge amount of trivial stuff that is reported makes the tool completely useless to me, at least on an existing code base. But code quality this is a very emotional topic, so I'm sure there are plenty of other opinions. :) -- 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.
