Interestingly we had a long discussion among developers yesterday here
over the differences between a solution with Hibernate/JPA and EmpireDB.
We came to the conclusion that
JPA puts the Java object into focus and wants to "just store it
somewhere", ideally completely shielding whatever underlying storage
technology is used, while
EmpireDB puts the relational database with all its functions and
features into focus. And a database is not just to store stuff and read
it back. It has lots of dedicated functionality to very efficiently work
with the data.
Consequently to me it seems to be wrong to see EmpireDB as a way to
persist objects. Rather it is a smooth interface to a database.
And if you rather need a database than "just get me these objects
stored", exploit the database and don't just focus on persistence.
I know this is not a very specific answer to your question, but maybe a
new perspective helps to figure out a better way to use EmpireDB --- or
rather something completely different, depending on what your data
really needs.
Just my personal opinion,
Harald.
On 29.08.2013 01:09, Tim Colson wrote:
Hi!
The team I'm working with has been experimenting with Empire DB in a small
Apache Click webapp for managing a Confluence wiki.
Our experience so far with no-strings has been good, but we'd appreciate advice
on how to best use Empire DB persistence patterns.
The webapp has five model objects, persisted to h2 for development / Oracle in
production. Maven, Spring for DI only, liquibase for DB migration,
TestNG/Surefire. We created a PersistenceManager class just like the Spring
example, and injected it with WikiMgtDB (extends DBDatabase), a DataSource, and
the Empire DB Driver. The PM class grew large with get/search/updates for the
business objects, so we created DAO classes for each model object and injected
each with WikiMgtD via Spring.
The PersistenceManager is injected into the Apache Click action classes for the
webapp and can retrieve/store objects, but is not much more than a proxy that
gives each DAO classes a Connection (see example).
PersistenceManagerImpl {
….
public SpaceSummary getSpaceSummary(String serverName, String spaceKey) {
Connection conn = getConnection();
spaceSummaryDAO.setConnection(conn);
SpaceSummary ss = spaceSummaryDAO.getSpaceSummary(serverName,
spaceKey);
releaseConnection(conn);
return ss;
}
This pattern seems wrong, and test cases cannot be written against the DAO
objects directly because they don't have a Connection.
(A related puzzle is connection and transaction management which has been
problematic with @Transactional annotations across updates involving more than
one DAO. )
I've looked over most all of the sample code, found a lot of good ideas, but I need
advice on EmpireDB patterns with more than one DAO, patterns for retrieving nested
objects, proper connection management, and also how to best handle "paged"
retrieval of 90,000 records.
Thanks in advance for any/all comments/feedback…and I'm happy to provide more
details and contribute lessons back into more example code. (ex, a sample
Apache Click + Empire DB)
Thanks!
Tim
--
Harald Kirsch
Raytion GmbH
http://www.raytion.com
