Hi bachew, were 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 couldnt 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. Were not looking to become as bad as the Galactic Empire though. So far were only just rebels in the universe of relational data persistence. But were 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 dont 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 - > http://incubator.apache.org/empire-db/empiredb/faq.htm. 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<http://incubator.apache.org/empire-db/empiredb/hibernate.htm>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. >
