Hi Aakash, First of all: I think this is the first post on your blog, right? Excellent first-time post, and we're very flattered that you've written about jOOQ as your first post. I've already had a couple of friends point the post out to me in the meantime. I've also noticed that you've posted it to /r/programming. It is a difficult environment. Have you considered /r/java as well? But it's a challenging topic. People might not read to the end before giving feedback...
Now for a bit of feedback from my side: *Methodology:* I really like the simplicity of the examples and how you build the article always pointing out that "in case of this or that added / removed complexity, a different route might be chosen". I think a new user will understand the purpose of your MockDataProvider implementation. So, definitely great kudos for your writing style! *Performance:* Perhaps, there are a couple of performance considerations to be made, as these SPI implementations really heavily influence the overall performance of your application (e.g visitEnd is really called for each and every QueryPart in each and every query that you're running). As always with such optimisations, measuring is important to see if the effect is significant: 1. in your MockDataProvider implementation, I'd delay generating the inlined SQL until it is really needed. The regular expression can match also on the SQL statement containing bind variables, i.e. the one from ctx.sql(). 2. in your visitStart() implementation, I suspect that you could abort execution early if the ctx.queryPart() instanceof Table check fails. This would save you from creating the Clause[] array and iterating through it. 3. the same is true for your visitEnd() implementation. While such optimisations are usually premature in normal environments, they're not in SPI implementations. I've tried to document this in the following blog post: http://blog.jooq.org/2015/02/05/top-10-easy-performance-optimisations-in-java It would certainly be interesting to point this out to the reader that they should be extra wary about performance within the VisitListener implementation. In fact, I'll add remarks to the Javadoc right now. *Correctness:* An interesting bit to mention would be the fact that your current visitEnd() implementation might not be entirely correct when you're in a derived table (although, the current example probably works for your specific use-case). You'll still be within the SELECT_FROM clause, but a new subselect has "started", and you should reset the nesting scope, because if you're in a subselect, you will also have to be inside the SELECT_FROM clause of that subselect, not only inside the one from the top-level select. Of course, that would be excessive for your examples, but it might be worth mentioning. Let me know if this makes sense. *Feedback:* What would be nice (but perhaps it's a little early for this) would be a section in the conclusion listing advantages and drawbacks of your approach. Perhaps, there are performance implications. Perhaps there were bugs or caveats in jOOQ or in redis, etc. You may be critical, of course :-) In any case, thanks again very much for this very useful article. We've linked it from jooq.org/community (you're lucky, the list is sorted alphabetically) and will keep posting it from our @JavaOOQ twitter account a couple of times. And of course, if you are interested in writing a follow-up post, I'll be very happy to assist you! Cheers, Lukas 2015-07-13 19:35 GMT+02:00 Lukas Eder <[email protected]>: > > > 2015-07-12 2:02 GMT+02:00 <[email protected]>: > >> Hey, >>> >>> >> So I ended up making that blog post, you can see it here: >> http://aakashjapi.com/caching-with-jooq-and-redis/ . Tell me what you >> think! Also ignore that earlier reply I made to this (that was send for >> review), I accidentally used my other email. >> > > Great news! I'll read through it in a bit and give you a reply by the end > of the week! > > Thanks a lot for providing all this insight. This is extremely useful for > us, and for the community. > > 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/d/optout.
