Re: JPA and desktop apps

From: <rsmogura(at)softperience(dot)pl>
To: PG-JDBC Mailing List <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: JPA and desktop apps
Date: 2010-07-22 10:22:40
Message-ID: e10739ad5d03f8985bc47f200d3fb0eb@smogura-softworks.eu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

JPA isn't wonder solution, it's works very good if you know it exactly and
know implementation of JPA you will use. Then when you create your
business
logic and database structure it can be optimized for JPA.

If you would like to go from legacy databases it can be sometimes
impossible (there can be problems with composite primary keys, working as
parts of FKs), but I saw one interesting way - create entities without
references. This means if A references B, then don't make reference, but
just put in A property bId, and then on demand load by
findById(,a.getBId()). Generally JPA isn't good for desktop applications,
this is due to transaction context (it can work without transactions,
ofc),
and on demand loading.

I use following way to speed up application.
1. First I create services for store/load.
2. For load I create search objects, that contains, if in need,
configuration parameters, from point of view of usage of searched objects.
Eg. UserSearch {nameLike ='%', wantGroups = true}
3. In this way service class can optimize read operations. When I don't
use eager fetching, I commonly use something like this or LEFT JOIN FETCH,
depends on configuration and provider
for (user : users)
if (user.groups.size > 0) users.groups.get(0);
this will pre-cache entities.
4. You need always refer to JPA provider implementations, for special
configuration parameters, query parameters, or additional annotations
(this
will make application less portable, but difference between JPA providers
are sometimes such big and on such basic things, that portability is
fiction, unless your queries will be "SELECT a FROM A a").
5. Use in queries LEFT JOIN FETCH, don't use eager loading unless objects
are in composition.
6. Build queries in dynamic way. This will allow you to change query
depending on search specification given in 2.
7. Treat JPA much more like read / write mapping to database, instead of
"make everything" utility.

Generally make service layer in your application and build specialized
facades in this layer for complicated methods.

Regards,
Radek

P.S.
I works long with JPA through Hibernate and Postgresql, I still getting
bugs and "surprises".

In response to

Browse pgsql-jdbc by date

  From Date Subject
Next Message Achilleas Mantzios 2010-07-22 11:12:08 Re: PostgreSQL JDBC vs jxDBCon as a model for other language implementations
Previous Message Tim Bunce 2010-07-22 08:54:02 PostgreSQL JDBC vs jxDBCon as a model for other language implementations