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 <[email protected]> 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 - > > 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. > > >
