Subject | DAO / Persistence layer |
---|---|
Author | Christian Stengel |
Post date | 2008-08-05T20:59Z |
Hi,
this is more an architectural question than an jaybird question - so
please forgive me, if I'm in the wrong place (but it's java / firebird
relevant).
I am wondering, how you implement your persistence layer within java
applications.
Today I have a web application using 100+ tables with stored
procedures, triggers, UDFs and so on. I have a hibernate / spring / zk
(ajax) framework combination and a plugin system to extend our own
pojos depending on customer needs.
I have the problem that changes done using plain JDBC are reverted by
hibernates storage mechanisms as those changes often are persisted
when flushing the session. The manual flush is no option as hibernate
throws unsaved transient exceptions when an hibernate pojo is extended
in one of our plugins.
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.
Do you use hibernate? If so do you use hibernate inheritance?
How do you deal with database constraints or exceptions? Do you use
them?
Do you use a layered architecture like DAOs, services and so on?
Do you use more advanced features of firebird like triggers,
procedures, exceptions, UDFs and so on?
How do you generate your metadata? Using Hibernate?
What about domains? Do you use them?
Which charset do you use ( I use utf8)?
Which persistence layer do you use (JDBC, spring, 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)
- Plain SQL commands are reverted by Hibernate (e.g. delete from xx
when using manyToOne relation ships)
- Inheritance requires Discriminator to determine Type
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). It is a lot of work, to keep
both systems in sync. How do you manage that? Do you let your pojos
define your database layer?
Thanks for your comments,
Christian
this is more an architectural question than an jaybird question - so
please forgive me, if I'm in the wrong place (but it's java / firebird
relevant).
I am wondering, how you implement your persistence layer within java
applications.
Today I have a web application using 100+ tables with stored
procedures, triggers, UDFs and so on. I have a hibernate / spring / zk
(ajax) framework combination and a plugin system to extend our own
pojos depending on customer needs.
I have the problem that changes done using plain JDBC are reverted by
hibernates storage mechanisms as those changes often are persisted
when flushing the session. The manual flush is no option as hibernate
throws unsaved transient exceptions when an hibernate pojo is extended
in one of our plugins.
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.
Do you use hibernate? If so do you use hibernate inheritance?
How do you deal with database constraints or exceptions? Do you use
them?
Do you use a layered architecture like DAOs, services and so on?
Do you use more advanced features of firebird like triggers,
procedures, exceptions, UDFs and so on?
How do you generate your metadata? Using Hibernate?
What about domains? Do you use them?
Which charset do you use ( I use utf8)?
Which persistence layer do you use (JDBC, spring, 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)
- Plain SQL commands are reverted by Hibernate (e.g. delete from xx
when using manyToOne relation ships)
- Inheritance requires Discriminator to determine Type
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). It is a lot of work, to keep
both systems in sync. How do you manage that? Do you let your pojos
define your database layer?
Thanks for your comments,
Christian