Hi,

We use Hibernate, so here is my experience:

> I think, that using hibernate as a persistence layer has advantages
> for "trivial" tables CRUD operations as used for lookup tables. But as
> soon as you dig into the world of process management with more complex
> objects you are stuck with unsaved transient instances or changes that
> are reverted by hibernate.

What do you mean by "reverted"?

> Do you use hibernate?

Yes.

> If so do you use hibernate inheritance?

Not much.

> How do you deal with database constraints or exceptions? Do you use
> them?

We rely on Hibernate to convert the SQL code into appropriate runtime
exception.

> Do you use a layered architecture like DAOs, services and so on?

DAO - yes, services - yes.

> Do you use more advanced features of firebird like triggers,
> procedures, exceptions, UDFs and so on?

Not really, but because of portability reasons. Triggers are used for
audit trail. Exceptions are too Firebird specific, procedures - rather
no (portability).

> How do you generate your metadata? Using Hibernate?

Modelling in UML (Enterprise Architect) -> generating DDLs -> create
database tables -> reverse engineering database tables into Java classes
and DAOs. Service interfaces are written by hand, service
implementations call DAOs, domain objects (Hibernate POJOs) are exposed
on interface level.

Transaction is automatically started when entering into service method,
automatically committed when exiting from the method or rolled back in
case of runtime exception. Checked exceptions are rarely used, but the
contract is to commit after them. We use dynamic proxies to wrap the
service implementations to handle the transaction boundaries. Services
are always stateless.

> What about domains? Do you use them?

No, portability reasons (also generating from UML makes things simpler).

> Which charset do you use ( I use utf8)?

ISO Latin 1 or UTF8.

> Which persistence layer do you use (JDBC, spring, Hibernate ...)?

Hibernate.

> We use all those features above - and we are stuck with the following
> problems:


> - implementation restriction exceeds messages (when hibernate
> generates SQLs using more than 64K)

There are few others, e.g. using parameters to shortcut the predicate
evaluation: :someParam = 0 or someCol = :someParam. Firebird has
problems with such queries.

> - Plain SQL commands are reverted by Hibernate (e.g. delete from xx
> when using manyToOne relation ships)

Please explain what do you mean here.

> - Inheritance requires Discriminator to determine Type

So what? :) It is just additional "technical" column - use CHAR(1) or
INTEGER.

> I use dbworkbench for database administration with "meaningful"
> constraint names and so on - so I disable hibernates auto ddl feature
> (although it could handle naming issues).

All constraints get their names in UML, rest is done automagically.

> It is a lot of work, to keep
> both systems in sync.

Hard issue. Usually we design in UML until things are pretty finished,
then generate Java classes from database schema. Consequent updates are
managed manually. But in general we have about 10 and 20 updates during
5-6 months of development, so it is manageble.

> How do you manage that? Do you let your pojos
> define your database layer?

We keep Java part in mind when designing tables, but database tables are
done first.

Roman