Skip to main content


Understanding Hibernate @BatchSize

Greetings! @BatchSize is one of those misunderstood concepts in Hibernate. I myself thought it was for the collection but I was wrong. Not convinced yet? let's find it out. (Simple example repo can be found here ) Let's assume we have a one-to-many relationship with Foo and Bar where Foo is the parent. Whether this is lazy or eager does not matter but I'll use Lazy loading. @Entity @Table(name = "foo") public class Foo { @OneToMany(fetch = FetchType.LAZY, cascade = CascadeType.ALL) @JoinColumn(name="foo_id") private List<Bar> bars = new ArrayList<>(); } I will have 5 Foos each having 10 Bars. for (int i = 0; i < 5; i++) { Foo foo = Foo.getInstance("Foo-" + i); for (int j = 0; j < 10; j++) { foo.addBar(Bar.getInstance("Bar-" + i + "-" + j)); } entityManager.persist(foo); } Single Entity When we try to access the Bar collection from Foo what

Ruling the code with Rules Design Pattern

Greetings! As a big fan of Chain Of Responsibility design pattern I was thinking to move out the if condition into a separate method so that I can loop through chain externally. It turned out that I end up implementing Rules Design Pattern. I first encountered the pattern few years ago in a C# article ( ). You can find the pattern in this course patterns-library . Rules Design Pattern In this pattern, we decouple the business rules from their processing by encapsulating them in to separate classes. We can add/remove rules without impacting the existing logic. This looks much like the Chain of Responsibility except processing rule is separated. One glitch I have faced is we are unable share one rules data with another as the rule and processing are decoupled. Anyway, it is worth to try. I'm not going re-invent an example. Instead i'll use the same example as in C# article but with minimum logic. public class Customer { pr

Let's Restore Agile

Greetings! I have been working in Agile environments for different companies for many years. We had/have a Scrum Master and Daily Standup, and that is it. That is Agile. This is what made me think "daily meetings are for bad managers". I started reading, practicing more on Agile and found this ( how-keep-your-team-from-getting-agile-wrong-hasitha-liyanage ) interesting article where I got more courage to apply Agile principles, values into my team. Where to Start? The first thing anyone should do is to read agile manifesto. It quite amusing that even certifed scrum masters/managers have no proper understanding on the manifesto. It Is Not About Processes The very first princile in Agile is "team over process". What does mean is, processes have value but the team has more value. For an example we don't need Daily meetings if the team decided so. It is the team decide how to work. Supoort and Trust Have you ever felt Trusted and Supported? If the answer is NO, you