2017-03-05 7:44 GMT+01:00 <[email protected]>: > Thank you. I closed the question on SO, and ended up using the 'force > static statement' approach described here: https://www.jooq.org/doc/3.9/ > manual/sql-building/dsl-context/custom-settings/ >
Yes, of course. That's a vaild workaround with one (potentially big) caveat (see below). > My typical JOOQ use case is like this (for both REST endpoint or fat > desktop clients) > > 1. fetch record from SQL (hand written, with bindings placeholder if > needed, e.g. "select * from book where book_id = ?") > 2. fetch into a pojo (can be jooq-generated, can be custom) > 3. manipulate the pojo > 4. when saving, create a new Record (e.g. BookRecord), copy data back > from pojo > 5. execute insert/update accordingly, taking care of the surrogate > primary key generation manually with a separate call (e.g. in master detail > situation) > > Do you see anything that would bite me if i use the 'force static > statement' setting globally? > >From a functional perspective, that's not a problem at all. From a performance perspective, it could be (and definitely would be in a high throughput Oracle or SQL Server application, for instance). >From what I understand, Firebird 3.0 now also implements a statement cache like most other databases: https://www.ibphoenix.com/resources/documents/general/doc_381 A statement cache skips the relatively costly prepare statement step where a SQL query is parsed (cheap) and an execution plan is calculated (expensive). If you run static statements, what used to be identical statements (SELECT * FROM t WHERE id = ?) will now be distinct statements that need separate parsing and plan calculation (... WHERE id = 1 / ... WHERE id = 2). For trivial queries, this might not be too big of an issue, but for complex ones, it will be, and you might run into statement cache contention issues as your cache would need frequent invalidation / emptying as you'll be filling your cache quickly. Unfortunately, this is a problem that developers hardly notice, because it becomes apparent in production systems only (under load). So, be careful with this workaround! Hope this helps, 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/d/optout.
