Re: JPA and desktop apps - Mailing list pgsql-jdbc
From | Samuel Gendler |
---|---|
Subject | Re: JPA and desktop apps |
Date | |
Msg-id | AANLkTimvDLO4Xa7F1QUL7U3zRHs-lF5e2uaxt6yuM9_7@mail.gmail.com Whole thread Raw |
In response to | JPA and desktop apps (Craig Ringer <craig@postnewspapers.com.au>) |
Responses |
Re: JPA and desktop apps
Re: JPA and desktop apps |
List | pgsql-jdbc |
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@postnewspapers.com.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@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-jdbc >
pgsql-jdbc by date: