Some time ago I noticed new library in our code base - Random Beans which as the name suggest is tool developed to easily create random data and random objects for testing purposes. Unfortunately we used it in the wrong way. Here’s how we backed up from the the random test data to regain control over testing.
Some time ago I’ve been trying to dynamically create spring beans. After fast stackoverflow check I decided to drop it and go with something else. Lately I’ve been trying to implement more complicated bean registration mechanism in which skipping dynamic bean creation wasn’t an option. Here’s how you can create spring beans “from code”.
Working with a lot of data using plain JPA or hibernate or spring-data is possible, it does work and usually it doesn’t require a lot of extra codding. Starting small is the fastest way of getting things done but you must be aware of few things that might shoot you in the foot.
Optimistic locking is concurrency control method that allows to execute multiple transactions simultaneously as long as they don’t interfere which each other. That’s definition from wikipedia. You probably already know that hibernate supports optimistic locking and all you have to do in order to implement optimistic locking in you app is to add @Version on number or timestamp field and you are good to go. Right?
Immutability and functional programming are hot right now. But how to achieve immutability with objects deserialized from json? Luckily there is pretty old feature introduced in jackson 2.7.0 which uses constructor based object creation and uses @ConstructorProperties (introduced in java7).
Every codebase depends on multiple external libraries. It is good idea to stay up to date with external dependencies. It is important to update all security related stuff and it might be helpful or fun to use latest features. I’m going to share my way of staying up to date with external dependencies in maven, gradle and npm.
Private final field modification is possible and it doesn’t require a lot of work. Since you should not use this mechanism in real life there are cases when it is useful. For example how is hibernate using this to hydrate final entity fields.
But when using final fields with hibernate you should be extra careful how you declare them.
Few days ago I’ve stumbled upon sql query performance issue. Git claims that I was the author so maybe that’s the reason I remember this feature. There was like 3 classes, everything was super easy and super fast all I needed to do was to let hibernate do it’s thing. Then time passed, new features were requested, model become more complex, number of rows increased to ~4 millions and original query became too slow.
When working on query optimisation I was really happy to find that detailed tests are in place. With proper test setup I was able to test my new query to make sure all requirements are met and then quickly copy paste query to sqldeveloper run it on test environment and verify if performance is acceptable. It wasn’t simple query and it took me some time to figure out how to make it quick and work exactly as old one. That was the time I was really glad that we invested in detailed unit tests in the beginning.
Sometimes when unit tests setup is complex we are tempted to take shortcuts and write single setup for all tests which will save as few keystrokes. In the time of writing the test it might feel like good idea to configure complex unit test setup and reuse it in all test. This way we avoid code duplication and we create more condensed test.
This approach looks good only in the time of the writing tests. Then there is a time when unit tests must be maintained. This is the time when you usually realise that saving few keystrokes wasn’t such a good idea.