Hi Aakash, I'm sorry for the delay - I had been on vacation, and our team hadn't picked up all the open conversations on the user group.
2015-06-24 0:25 GMT+02:00 <[email protected]>: > Hey, > > So the cache is working now, and it will soon be deployed into our > production environment. I'm working on the logical next step, which is to > change a lot of our queries to improve cache performance, doing things like > reducing the granularity of timestamps (rounding to the nearest hour rather > than the current millisecond when we can, for example) so queries can be > reused. A major problem with this is that we currently use a lot of JOOQ's > automatically generated aliases (so like, alias_393222), which cause > unnecessary cache misses. > > We have a lot of queries already written, so I'd like to avoid having to > go through and manually attach a .as() statement to each one. Is there > anything else I can do to resolve this issue? Maybe edit the query through > the VisitListener again or something? > That's an interesting point. SQL doesn't really have a useful syntax for this, although it would be nice to be able to rename the batch of SELECT fields in one go, similar to common table expressions, but without the execution plan implications that CTE's often have (such as materialisation). The generated aliases use hash codes. Future jOOQ versions might assign indexes instead, but in the past, we've found indexes to be dangerous in the context of potential VisitListeners, plain SQL or other means of interaction... I'd like to understand more about this use-case. How does it apply, exactly? -- 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.
