Re: JPA and desktop apps

There's no one good answer to your question, although you've gone a
long way to answering it with this: "while lazily fetching properties
of entities to avoid downloading half the database whenever you query
it for anything." Quite simply, you cannot allow the UI to access
lazily fetched properties if you cannot tolerate the UI blocking while
it loads. I don't use JPA, but I do use hibernate, and removing the
JPA layer gives me a much richer API for interacting with hibernate.
I can write an HQL query which loads the properties that I know will
be utilized in a particular context, avoiding lazy loading, even
though my mappings support it (look for "join fetch" in the hibernate
HQL docs). I can disable lazy loading entirely in my mappings, or
control it via my mappings and ensure that things are fetched in
chunks larger than my UI displays them. When it comes to web services
type apps, which often serialize objects out to a remote client, I use
something like dozer to map my hibernate objects over to plain beans
in my controller via a mapping that only copies the properties I care
about, otherwise every request tends to get a copy of most of the db.
Then the view deals only with the non-hibernate versions of your
objects. There are a variety of approaches you can use, but which one
works best will inevitably be application and schema dependent. I will
say that I've had no luck using any of the automatic marshaling
frameworks precisely because they wind up iterating over the entire db
when you serialize a single object. I always wind up mapping to
non-hibernate objects and then marshaling those, which adds latency
and workload, though this is very unlikely to be noticeable on a
single-user desktop app.

--sam

On Wed, Jul 21, 2010 at 8:07 PM, Craig Ringer
<craig(at)postnewspapers(dot)com(dot)au> wrote:
> Hi all
>
> This is mildly OT, so please ignore unless you're interested in and work
> with PostgreSQL via JPA/Hibernate/EclipseLink/etc in a desktop app setting.
>
> Ages ago, I asked here if others were using JDBC directly to access Pg
> from their java apps, or if they were using an ORM. I sought advice.
> Many suggested that an ORM was a strongly preferable option, and partly
> as a result of that advice I ended up using the JPA interface (with
> Hibernate powering it) for my database access in my Swing app.
>
> I've now concluded that, while it seems great on the surface, that
> approach is absolutely awful, because of issues with detatched entities,
> lazy property fetching, and the need to run database work on a non-EDT
> thread to avoid UI stalls/freezes and repaint delays.
>
> More details here:
>
> http://soapyfrogs.blogspot.com/2010/07/jpa-and-hibernateeclipselinkopenjpaetc.html
>
> Anyway, since folks here advised me to go for an ORM like Hibernate, I'm
> curious: How do you handle the need to avoid blocking on database access
> in your Java GUI apps, while lazily fetching properties of entities to
> avoid downloading half the database whenever you query it for anything?
>
> --
> Craig Ringe
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc
>