I’ve never thought I would see an unresponsive server due to a bad regex matcher but that’s just happened to one of our services, yielding it unresponsive.
Let’s assume we parse some external dealer car info. We are trying to find all those cars with “no air conditioning” among various available input patterns (but without matching patterns such as “mono air conditioning”).
The JDBC API has always been cumbersome and error-prone and I’ve never been too fond of using it. The first major improvement was brought by the Spring JDBC framework which simply revitalized the JDBC usage with its JdbcTemplate or the SqlFunction classes, to name a few. But Spring JDBC doesn’t address the shortcoming of using string function or input parameters names and this opened the door for type-safe SQL wrappers such as jOOQ.
JOOQ is the next major step towards a better JDBC API and ever since I started using it I knew there was no turning back. JOOQ became my number one choice for building dynamic queries and recently it became my standard SQL function wrapper.
Code review is a great software instrument and you should definitely use it to improve the quality of your code. But like any other tool, it may be misused sometimes. That’s why I came up with a list of best practices to guide you when reviewing your peers’ code.
Code review is not testing: Code review is a developer-to-developer business and it doesn’t involve any testing. Code review should check if the task requirements are met in the cleanest possible way.
You don’t tell what to code review: The same way you don’t tell a tester what to test, you should never tell your peer what to review. The magic of peer review comes from your peer own perspective on the current task design and implementation. Two minds are always better than one.
You should always check all changes: Bugs may be hidden anywhere and you should search for them diligently. To have the whole picture you need to go through all changes.
Requirements first: Requirements are the most important driving force. After all, that’s what the customer is paying for. If the current changes are suboptimal you need to reopen the issue. If you happen to spot other code sections that need to be refactored you should create new issues instead of reopening the current one. The “single responsibility principle” applies to tasks as well as to coding.
One-to-many activity: If you can’t make sure you grasp the code change intention it’s safer to ask somebody else to review it further.
A way of learning: Code review is a great learning technique especially on large projects. Ideally, you should become familiar with every aspect of your project, but if the project is too large you can at least specialize in multiple modules.
Hibernate simplifies CRUD operations, especially when dealing with entity graphs. But any abstraction has its price and Hibernate is no different. I’ve already talked about the importance of fetching strategy and knowing your Criteria SQL queries, but there is more you can do to rule over JPA. This post is about controlling the SQL statement count that Hibernate calls on your behalf.
Before ORM tools got so popular, all database interactions were done through explicit SQL statements, and optimizations were mostly targeted towards slow queries.
If you think that using Hibernate absolves you from worrying about the underlying SQL statements, then you are wrong. Hibernate is supposed to ease domain model persistence, not to free you from any SQL interaction.
With Hibernate, you manage entity state transitions which are then translated to SQL statements. The number of generated SQL statements is affected by the current fetching strategy, Criteria queries or Collection mappings and you might not always get what you expected. Ignoring SQL statements is risky and it may eventually put a heavy toll on the overall application performance.
I’m a strong advocate of peer review, but that’s not “sine qua non” for detecting bad Hibernate usage. Subtle changes may affect the SQL statement count and pass unnoticed through the reviewing process. Not in the least, when it comes to “guessing” the JPA SQL statements, I feel like I can use any extra help. I’m for as much automation as possible, and that’s why I came up with a mechanism for enforcing the SQL statement count expectations.