incubator-empire-db-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francis De Brabandere <>
Subject Re: More history of Empire-db
Date Mon, 02 Feb 2009 12:21:50 GMT
Hi bachew,

Interesting to see you're integrating Wicket and Empire-db, I'd like
to know how you are handling the integration. Keep us updated on your

On Mon, Feb 2, 2009 at 8:21 AM, bachew <> wrote:
> Hi,
> Thanks for the details. Actually as an sane object oriented programmer came
> from C++ like you, I understand that API is above everything, metadata
> (annotation and XML) are very well just implemented using API. To use JPA
> would mean I'm stuck without the ability to intuitively get metadata in
> runtime. People were trying to pretend that SQL does not exist, but we all
> know it will exist for a very long time.
> I need SQL abstraction library but I don't have the time to write it,
> Empire-db looks exactly what I need, I haven't tried it though, will try
> once I'm back from holiday and finished up tasks at hands.
> Actually I have been gathering like-minded projects, like-minded in terms of
> focus on getting API right, making most, if not everything dynamic. We've
> got Guice for dependency injection, Wicket for web framework, Jetty for
> embedded web server, Restlet for REST service and hopefully Empire-db for
> database.
> I'm not building something sophisticated, just want a real object oriented
> Java application framework to save our fellow Java developers precious time.
> It's simply sickening for me to maintain someone else's applications written
> in JPA, struts, JSP, JSF, spring moster xml, etc.
> On Sun, Feb 1, 2009 at 6:39 PM, Rainer Döbele <> wrote:
>> 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
>> Rainer
>> 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.
>> >

Microsoft gives you windows, Linux gives you the whole house.

View raw message