Mailing-List: contact users-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@openjpa.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
From: Jean-Baptiste BRIAUD -- Novlog <j-b.briaud@novlog.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Subject: OpenJPA rock and fetch plan is a killing feature.
Date: Mon, 31 Jan 2011 20:26:44 +0100
Message-Id: <09057867-617A-4DF2-8C69-A6ED1BD518EB@novlog.com>
To: users@openjpa.apache.org
Mime-Version: 1.0 (Apple Message framework v1082)

Hi the list,

I realize I often post when I have a question or when something goes =
wrong.
I decided to post because I'm happy with OpenJPA and everything is fine.

I'd like to share I'm really happy with fetch plan that we use heavily.
As a consequence, we are no more using lazy loading at all.
Instead, we're defining what we need using fetch plan and get only what =
we need.

We didn't have time to test under heavy load or with a heavy database =
but one of our customer did compare the new system we made to previous =
system and feel it is really quicker.
Nothing prove it is due exclusively to fetch plan but it is still =
positive.

Let me try to quickly explain the benefit of fetch plan.

Say we have to cook that French cake "Charlotte aux fraises".
Using lazy loading, here what's happen :
1. OK, I need 10 strawberry, let's run to the shop and comeback quickly.
2. read the cook book further : I also need those special element =
"biscuit a la cuilliere",
OK, let's go to the shop
3. read next step ...

Guess what, it is slow and I get bored to go to that shop every time !

Now, let's use fetch plan :
1. Read the cook book for "Charlotte aux fraises".
Ok, I need 10 strawberry and some "biscuit a la cuilliere".
2. Go to the shop and buy everything at once, following a list I've =
written.
3. Cook that cake without going to the shop anymore.

I just can't understand why fetch plan approach is not the default way.
... and with fetch plan too I could add cache and this could speed up =
things.
For lazy loading, cache is not an answer, it is a way to hide problems =
or more precisely, to hide my ignorance about what exact data I need as =
a Java developer.
What's the point of doing OO model in UML if that information is ignored =
because of lazy loading ?
The danger, and I met that situation often on customer cases, is to =
loose the control.
Sometimes, no one in the dev team know exactly what data is used because =
of lazy loading.
In some hard case, one have to reverse engineer by spying SQL to recover =
information of what part of the app need what data.
Also, concurrency become harder to solve because data dependencies are =
not written anywhere.

So, lazy loading in some particular cases, why not, but default approach =
should be using fetch plan.
On the other hand, we were not in the case of very very complex request =
or "action" in the database.
Even in such cases, I'm not sure lazy loading would helps.

Conclusion : thanks OpenJPA, you're the only one I know with such =
powerful feature.
I stop using Hibernate because fetch plan was missing (and the code was =
easy to migrate).

JBB.

---
The data I need and only the data I need.