Hi,

> > objects you are stuck with unsaved transient instances or changes
> that
> > are reverted by hibernate.
>
> What do you mean by "reverted"?
>

Some changes are overwritten or deleted by hibernate as hibernate
writes data on flush() or on commit(). A SQL command is executed
immediately. I had those problems with n:m relation ships, where the m
side of the pojo was kept empty because of performance reasons. The
initial values where added to the table in a INSERT INTO SELECT
command - but hibernate generated a DELETE for that list on flush.
Unfortunately I was not able to perform this flush before the delete.

That't the same way with stored procedures - if they are called by
plain JDBC changes might be reverted.

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

OK - so you don't mix it. That's our approach now too - but in my
opinion this is a bit slower than performing datachanges in stored
procedures or plain sql (depending on your needs).

>
>
> > - Plain SQL commands are reverted by Hibernate (e.g. delete from xx
> > when using manyToOne relation ships)
>
> Please explain what do you mean here.
>

see above - reverted :)

>
>
> > - Inheritance requires Discriminator to determine Type
>
> So what? :) It is just additional "technical" column - use CHAR(1) or
> INTEGER.
>

Yes - technically speaking but but ... :). We use inheritance with
multiple layers. If you perform a myobject.getPerson().getId() and the
getPerson is type of basePerson you usually get the base person - not
the customer person attached to that object.

Or if you have a customer, that is satisfied with the base person but
likes to have a customer person after a while you cannot simply
upgrade - newly created persons are stored with the new type and have
the new properties - old persons are kept with the old value and don't
have the new properties. So you have to deal with that in your
deployment process.

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

what uml tool do you use?

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

Thanks for your answers,

Christian