incubator-empire-db-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Döbele <>
Subject re: More history of Empire-db
Date Sun, 01 Feb 2009 10:39:07 GMT
Hi bachew,

we’re glad to hear that you like Empire-db. We really believe it's the best thing since sliced
bread and we hope more and more people will see the advantages.

About the history:
The basic idea, i.e. to describe the data model using classes and objects goes back to the
middle of the 90's. At that time I was developing document management solutions under Windows
using C++ and MFC. Back then I wrote the first attempt for a relational data persistence layer
in C++. 

In 2000 me and my partner founded our company ESTEAM Software now focusing on developing Web-based
applications in Java. For our first big project I used all the ideas from my C++ implementation
to build a data persistence layer in Java. Since then we have used and improved the library
(I don't want to use the word 'framework' in this context) in many fundamentally different
applications such as CRM-tools, DataWarehouse utilities, Supply-Chain-Management etc. and
for both Web and Rich-Client applications. Besides the Java implementation we also have a
C# implementation; however we have not yet found the time to separate it from other stuff
and make the necessary refactorings to match it with our Java Empire-db. We might do that
I we find there is demand for it.

Most applications that we have implemented were relying heavily on data gathered from various
tables by complex queries with varying constraints and joins which are built at runtime. Also
as applications and data model change we needed something that gives us maximum security that
when we change the model the application will still work - or the compiler should give us
an error. This is why we tried to avoid using strings for column or table names completely
- except for the model definition of course.
This has many times saved our lives and I really can't see how people could possibly survive
with traditional OR-Mappers except for the simplest type of database activity.

Finally about the name:
This is a rather boring story. First, as we had the 'e' for our jsp-tag library originally
taken from our company name "ESTEAM" we were looking for a name that also started with an
‘e’. Second it had to be a simple word as we couldn’t think of a suitable idiom. And finally
since my kids have made me live in a parallel Star Wars universe for the last couple of years
“Empire” was the closest match. We’re not looking to become as bad as the Galactic Empire
though. So far we’re only just rebels in the universe of relational data persistence. But
we’re determined to take on all these Hibernates and JPA implementations out there and maybe
one day we will make the world a better place :-)

The two example applications provided with the core and the web-demo application provided
with the struts extensions should give you a good idea about most of the functionality and
how to apply it. However most people when starting to use Empire-db make things more complicated
than necessary. So if you face any difficulties or think there must be a shorter easier way
to achieve something don’t hesitate to ask.

On the other hand we are curious to hear what kind of solution you have implemented with Empire-db.
Best regards


bachew wrote on Fr 30.01.2009 03:18
> Re: More history of Empire-db
> Hi,
> The first entry in the FAQ answered part of my question -
> But I would like to
> know more about the history of Empire-db, the people and the organization
> behind this interesting library. How it improves over the years and what
> kinda applications that Empire-db is written for. And erm... why name it
> Empire-db?
> Hard to believe that someone finally did what I have in mind and this
> page<>explained
> what I always wanted to explain to people. I'm planning to write
> an application framework and it seems my only choice is Empire-db on
> database side, I wish to know more about it.
> Thanks in advance.

View raw message