Re: JPA and desktop apps

On 28/07/10 04:35, Guy Rouillier wrote:

> Our team is proficient in SQL and JDBC, so we wanted something that
> would take care of all the routine housekeeping but would not be as
> bloated as JPA or Hibernate. We settled on MyBatis
> (http://www.mybatis.org/) formerly iBATIS.

How did you find that it played with Pg features like:

- Custom and domain types
- User/role security
- column privileges

?

I had to fiddle a bit to make Hibernate play well with per-user logins.
It wants a single all-powerful database login and security implemented
in the app. I prefer someone else's already-tested security system to
inventing my own, so I was using user rights in the database. I had
issues making Hibernate log in with a dynamic username/password, though
they weren't overly difficult to overcome. It also took some fiddling to
make Hibernate only list changed columns in UPDATE and INSERT queries so
it'd play well with column privileges.

iBatis / MyBatis looks *much* more like what I'm after in most ways, but
I'm a bit concerned about managing column privs. If simple INSERT/UPDATE
queries are hand-coded then it's going to take some interesting fiddling
to avoid trying to touch columns a user doesn't have the rights to
update. I'm concerned I'd have to write too many very similar queries.
In this particular area, Hibernate is a real boon - well, once I
convinced it to generate dynamic queries.

The security model isn't so complex that I can't just have a few
different UPDATE queries for different rights levels, but I'm hoping to
avoid it.

Have you dealt with this? Or do you not use column privs?

I'm still cursing the design of column privs in SQL. Requiring that cols
not even be listed in an UPDATE if you don't have UPDATE rights to them
- argh! It should be allowed to UPDATE a column to an identical value,
ie UPDATE x SET a = 'old-value-of-a' so long as you have at least SELECT
rights on that column. I'm sure there are good reasons it's how it is,
but it really, really stinks from an application dev point of view, and
SQL didn't need any more clumsy dynamic query construction crap than we
already have to deal with.

--
Craig Ringer

Tech-related writing: http://soapyfrogs.blogspot.com/